Skip to main content
The sandbox runs the same code as production and exposes the same operations. Accounts, balances, transactions, minting, webhooks and payouts all behave as they do live.

​
What is real and what is not

Real

Account provisioning, the reconciliation and minting pipeline, balances, transaction records, webhook delivery and signing, payout submission, and FX quoting.

Simulated

The two fiat legs only — money coming in over the bank rail, and money going out to a bank account. Nothing settles at a real bank.
Because only the fiat legs are simulated, a sandbox deposit runs through the same reconciliation and mint path as a production one rather than being injected at the end. What you exercise is the real pipeline.

​
Boundaries

​
Getting access

Sandbox sign-up is self-serve and takes a few minutes. Go to dashboard.stablemint.net, sign up with your work email address and confirm the code sent to it. A sandbox partner and a dashboard login are provisioned at the end of it — no StableMint contact is involved.
Two-factor authentication is mandatory and cannot be deferred. Sign-up enrols an authenticator app (TOTP) before it completes, so have one to hand. Store the recovery codes: losing them locks you out of the dashboard, and with it the Developer Hub where service-account keys are managed.
Once you are in:
1

Create a service account

In the Developer Hub, generate an RSA key pair and register the public key. See Service accounts.
2

Sign your first request

Call GET /v1/accounts to confirm your signing implementation is correct before writing anything else. See Authentication.
3

Create a customer

POST /v1/customers, then POST /v1/customers/{id}/account to provision their account details.
4

Simulate a deposit

Fabricate an inbound payment against those account details, and watch it reconcile and mint.
5

Receive the webhook

Register a subscription and verify the signature on the delivery.
Sandbox API keys carry an sk_live_ prefix. It is not an environment marker and does not mean you are holding a production credential. Sandbox and production are separate estates with separate credentials, and neither works against the other — but the prefix will not tell you which one is in your hand, so key your own configuration on the base URL, never on the shape of the key.

​
Simulating a deposit

Simulating a deposit is how you drive the rest of a flow without moving real money: it credits your sandbox account exactly as an inbound bank transfer would, and everything downstream — minting, balances, transactions, webhooks — happens for real.
POST /v1/simulations/deposit exists only outside production. It is absent from the production route map entirely, so calling it against https://api.stablemint.io returns 404 — not a permission error. Never make it part of a code path that also runs in production.
​
number
required
Must be greater than zero.
​
string
required
EUR or USD.
​
string
Required when reference is not supplied. Targets one of your own provisioned accounts. The example above uses this form, which is the one to reach for when you just want funds to arrive.
​
string
Targets a pending deposit that already exists and is still unpaid.
reference is not a free-text label, and sending one commits you to it. When both are supplied, the reference is resolved first and the IBAN is used only to confirm it points at the same account — there is no fallback to the IBAN if the reference matches nothing. A reference with no pending deposit behind it fails with 400, however valid the IBAN is.So send a reference only to fund a deposit you created earlier with POST /v1/customers/{id}/deposit (see Customers), and send back the reference that call returned. To simulate money simply landing on an account, send iban alone.
A request that resolves neither a pending deposit nor an account you own returns a single generic error — no detail about other partners’ records is returned.
You can only simulate deposits against account details you own. There is no way to target another partner’s account.

​
Payouts and payee verification

Outbound payouts complete against the bank’s own sandbox, so payee verification, FX and settlement behave like the real thing. Any well-formed IBAN is accepted; malformed ones are rejected at validation.
A documented set of test account details that drive payee verification to each outcome — match, close match, no match, unavailable — is being published. Ask your StableMint contact for the current list in the meantime.

​
Going to production

When you move across, three things change and nothing else does:
  1. The base URL becomes https://api.stablemint.io.
  2. You use production credentials from a production service account.
  3. Deposit simulation is gone — money arrives over the real rail.
Because the surfaces are otherwise identical, a working sandbox integration is a working production integration.