The three kinds of key
A key is minted in the dashboard and returned exactly once. Only a selector and a hash of the verifier are stored, so there is no reveal endpoint and there never will be.
ib_sk_live_…Secret key
Server-side only. Full merchant authority, and optionally bound to one wallet so a key separates one project’s money from another’s.
ib_pk_live_…Publishable key
Safe in a browser or an app. It can create and confirm payments and nothing else — it cannot list transactions or read a balance.
ib_rk_live_…Restricted key
Server-side, limited to an explicit list of permission scopes. One per integration, so a compromise has a blast radius rather than a total.
Scopes
A restricted key carries permission codes and may exercise only the intersection of its own scopes and what its merchant is allowed to do. Widening a merchant’s permissions never silently widens a key.
Test and live
The environment is encoded in the key itself — ib_sk_test_… or ib_sk_live_… — and is never inferred from a header, a hostname or a request field. A test object is unreachable from a live key and the reverse.
IP allowlist
Each key can name the source addresses permitted to use it. It defaults to empty, meaning any address, because a merchant on dynamic egress would otherwise lock themselves out — but on a fixed egress it is the strongest single control you have.