> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stablemint.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Sandbox
> A full-parity environment where only the fiat legs are simulated.
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.
```
https://api.stablemint.net
```
## What is real and what is not
Account provisioning, the reconciliation and minting pipeline, balances, transaction records,
webhook delivery and signing, payout submission, and FX quoting.
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
| | Sandbox |
| ----------------- | ---------------------------------------------------------------- |
| Currencies | EUR and USD |
| Data | Not verified, and need not be real |
| Compliance checks | Not performed on sandbox identities |
| Reset | Not supported — create new records rather than clearing old ones |
| Credentials | Separate from production and not interchangeable |
## Getting access
Sandbox sign-up is self-serve and takes a few minutes. Go to
[dashboard.stablemint.net](https://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:
In the [Developer Hub](https://dashboard.stablemint.net/), generate an RSA key pair and
register the public key. See [Service accounts](/guides/service-accounts).
Call `GET /v1/accounts` to confirm your signing implementation is correct before writing
anything else. See [Authentication](/guides/authentication).
`POST /v1/customers`, then `POST /v1/customers/{id}/account` to provision their account details.
Fabricate an inbound payment against those account details, and watch it reconcile and mint.
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.
```bash theme={null}
curl -X POST https://api.stablemint.net/v1/simulations/deposit \
-H "ApiKey: $STABLEMINT_API_KEY" \
-H "Timestamp: $TIMESTAMP" \
-H "Nonce: $NONCE" \
-H "Signature: $SIGNATURE" \
-H "Content-Type: application/json" \
-d '{
"amount": 100.00,
"currency": "EUR",
"iban": "SE4330000000000123459485"
}'
```
**`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.
Must be greater than zero.
`EUR` or `USD`.
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.
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](/guides/customers#create-a-reference-based-deposit)),
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.