Why use the Institutional API
Without the Institutional API, every counterparty that needs to mint or redeem through Circle would have to onboard as a direct Circle Mint customer. The Institutional API solves that by letting one Distributor’s Mint account act as the integration surface for many institutional end clients. Circle still runs compliance on each external entity, but the Distributor—not the end client— holds the API key and runs the integration. The API is intended for B2B2B Distributors servicing institutional end clients, such as:- Commercial banks
- Institutional banks
- Centralized exchanges
- Custodians
- TradFi trading platforms
- Real-world asset (RWA) platforms
Distributor and external entity
The Institutional API revolves around two roles. The Distributor is the Circle Mint customer; the external entity is the Distributor’s institutional end client. Each role has a different relationship to Circle and to the API.Compliance lifecycle
Every call toPOST /v1/externalEntities
triggers a synchronous sanctions screening on the entity’s business name, tax ID
(businessUniqueIdentifier), issuing country code, and address. The 201
response returns the entity in complianceState: PENDING along with the
provisioned walletId. The final decision—ACCEPTED or REJECTED—is delivered
asynchronously through the externalEntities webhook topic.
The walletId is returned at creation but is unusable while the entity remains
in PENDING or REJECTED. Wait for the externalEntities webhook to deliver
complianceState: ACCEPTED before referencing the entity’s wallet in any other
endpoint.
Per-entity wallet model
When Circle accepts an external entity, it provisions a dedicated wallet of typeend_user_wallet and surfaces the wallet identifier as walletId (for example,
"212000"). The wallet is owned by the Distributor’s Mint account but
segregated to that entity, so balances and money movement remain attributable
per counterparty.
Every relevant Mint endpoint accepts the entity’s walletId:
- On
GETendpoints (such as listing deposits, payouts, or transfers), pass the entity wallet as thewalletIdquery parameter:?walletId=212000. - On
POSTendpoints (such as creating a payout or an onchain transfer), pass the entity wallet in the request body as"source": { "type": "wallet", "id": "212000" }.
walletId is omitted on a request, Circle defaults to the Distributor’s
primary wallet (masterWalletId). The primary wallet remains available for the
Distributor’s own balances and money movement; the entity wallets sit alongside
it as siblings, not as children of the primary wallet.
Operational flows
The Institutional API supports three flows on behalf of an accepted external entity: minting, redeeming, and onchain transfer. The table below summarizes each flow at a conceptual level. For endpoint-level steps, see Manage institutional subaccounts.Billing
Institutional Direct is the default billing model for the Institutional API. A gross flat fee is applied to every redemption, charged to the end client at the point of redemption and deducted from thetoAmount returned on the payout
response. The Distributor sees the net amount in the payout payload, and the
entity’s bank receives that net amount.
Alternative billing models are available by exception. Contact Circle to
arrange one outside the API.
What is not supported
The Institutional API does not support the following operations on behalf of an external entity:- Editing or deleting an external entity once it is created. Contact Circle to make changes.
- Express routes from entity subaccount wallets.
- Local-currency onramp flows (such as BRL, MXN, or EURC swaps) on behalf of entity subaccounts.
- Stablecoin Payins and Stablecoin Payouts against entity wallets.
- Cross-Currency Exchange against entity wallets.
- Credit API operations on behalf of an external entity.