Quickstart
Sign your first request and read your account balance.
Sandbox
A full-parity environment with simulated fiat legs.
Authentication
Service accounts and RSA request signing.
Service accounts
Credentials, permissions and rotation.
The model
There are two kinds of account, and the distinction runs through the whole API.you
Your own organisation. You hold accounts and balances, you make payouts, and you manage service
accounts and team members.
your end users
A customer you create and operate on behalf of. Each one can be provisioned its own account
details, receive deposits, and hold a balance that is segregated from yours.
What a full cycle looks like
1
Create a customer
POST /v1/customers, then provision their account details with
POST /v1/customers/{id}/account.2
They fund it
Money arrives on the bank rail against their account details. StableMint reconciles the
inbound payment and mints the corresponding stablecoin.
3
You are notified
A signed
partner.customer.deposit.completed webhook fires, carrying the amount, currency and
blockchain transaction hash.4
You pay out
POST /v1/payouts/fiat to a bank beneficiary, or POST /v1/payouts/token to a wallet. Both
are single, idempotent, unattended calls.Base URLs
Both environments run the same code and expose the same operations. The only deliberate
differences are how you get in and that sandbox money is not real — see
Sandbox.
Before you start
The API accepts service-account signed requests only. There is no bearer-token access, no
OAuth client-credentials flow, and no API-key-in-a-header shortcut. Every request carries four
headers and an RSA signature over a canonical string. Start at
Authentication.