> ## Documentation Index
> Fetch the complete documentation index at: https://docs.antonpayments.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Sandbox Test Data
> Reset your sandbox to a clean state and seed realistic beneficiaries, instruments, and payouts with a single call each.
The sandbox gives you three endpoints to manage test data for your merchant:
* `POST /v1/merchant/sandbox/reset` — wipe and optionally reseed
* `POST /v1/merchant/sandbox/seed-beneficiaries` — generate sample beneficiaries across multiple countries and methods
* `POST /v1/merchant/sandbox/seed-payouts` — generate sample payouts in mixed states for UI and webhook testing
All three are **sandbox-only** — calling them against production returns `403 sandbox_only`. They're scoped to your merchant — you can't affect another merchant's data.
## Reset
Four reset scopes:
| `?scope=` | What it does |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `balances` (default) | Wipe `merchant_accounts` + sandbox transactions, re-seed fresh balances. Beneficiaries, instruments, and payouts stay. |
| `all` | Wipe payouts, instruments, beneficiaries, and sandbox transactions. Re-seed currency balances only. |
| `delete-all` | Wipe everything. No reseed. You land at zero state. |
| `full-reset` | Wipe everything. Re-seed balances + sample beneficiaries + sample payouts. Equivalent to a fresh merchant with demo data. |
```bash theme={}
# Clean balances, keep your beneficiaries and payouts
curl "https://api.antonpayments.dev/v1/merchant/sandbox/reset?scope=balances" \
-X POST \
-H "Authorization: DPoP $ANTON_ACCESS_TOKEN"
# Nuclear option — fresh merchant state with demo data
curl "https://api.antonpayments.dev/v1/merchant/sandbox/reset?scope=full-reset" \
-X POST \
-H "Authorization: DPoP $ANTON_ACCESS_TOKEN"
```
Rate-limited to 10 resets per merchant per hour — enough for active development, tight enough to catch a runaway test suite.
Response:
```json theme={}
{
"status": "reset",
"scope": "balances",
"merchant_id": "mer_01HX..."
}
```
`status` varies by scope:
* `balances` → `"status": "reset"`
* `all` → `"status": "cleaned"`
* `delete-all` → `"status": "deleted"`
* `full-reset` → `"status": "reset"` with extra counts for the sample data that was re-seeded
`full-reset` adds `beneficiaries`, `instruments`, and `payouts` counts so the
dashboard can render a confirmation toast without a second call:
```json theme={}
{
"status": "reset",
"scope": "full-reset",
"merchant_id": "mer_01HX...",
"beneficiaries": 4,
"instruments": 4,
"payouts": 4
}
```
## Seed sample beneficiaries
Creates a curated set of realistic beneficiaries across multiple countries and payment methods — useful for populating your UI or testing country-specific edge cases:
```bash theme={}
curl https://api.antonpayments.dev/v1/merchant/sandbox/seed-beneficiaries \
-X POST \
-H "Authorization: DPoP $ANTON_ACCESS_TOKEN"
```
Response:
```json theme={}
{
"status": "seeded",
"merchant_id": "mer_01HX...",
"beneficiaries": 4,
"instruments": 4
}
```
`beneficiaries` is the number of beneficiary records created; `instruments`
is the number of payment instruments attached across those beneficiaries
(usually one per beneficiary, but kept separate so the response shape stays
honest if the seeder later creates multi-instrument beneficiaries).
The beneficiaries created include a mix of `individual` and `business` types, spanning several corridors — enough variety to exercise most payout flows without you having to construct PII by hand.
## Seed sample payouts
Creates payouts in a mix of states — `completed`, `failed`, `cancelled`, `manual_review`, and in-flight — so you can validate your UI and webhook handling against every outcome:
```bash theme={}
curl https://api.antonpayments.dev/v1/merchant/sandbox/seed-payouts \
-X POST \
-H "Authorization: DPoP $ANTON_ACCESS_TOKEN"
```
```json theme={}
{
"status": "seeded",
"merchant_id": "mer_01HX...",
"created": 4
}
```
`created` is the number of sample payouts created — one per seeded
beneficiary, cycling through the four outcome triggers (happy path, slow,
return, failure).
**Requires seeded beneficiaries first.** Running seed-payouts with no beneficiaries returns `422 no_beneficiaries`. Call seed-beneficiaries first, or use `?scope=full-reset` on the reset endpoint which seeds both.
## Using these in CI
A recommended CI pattern:
`POST /v1/merchant/sandbox/reset?scope=delete-all` to guarantee a clean slate.
If your tests need a starting population (e.g., dashboard snapshot tests), call `seed-beneficiaries` and `seed-payouts`.
Exercise your real integration against the seeded state.
`?scope=balances` is faster than a full reset — keeps your seeded data, resets funding state.
Rate limits apply across the hour: 10 resets per merchant per hour. In a heavy-test CI setup, either share a merchant across workers carefully, or provision multiple sandbox merchants.
## Triggering specific scenarios (future)
Sandbox seeders produce a curated distribution — payouts in mixed states, beneficiaries across corridors. For deterministic triggering of specific engine verdicts, screening hits, or rail failures, that's forthcoming functionality — when it lands it'll use the `?simulate=` query parameter on `POST /v1/payouts` (sandbox-only). Watch the [changelog](/changelog) for when it ships.
## What's different from production
See [Sandbox Overview](/sandbox/overview) for the full list. Key points:
* Rail submission is mocked — no real banks are contacted
* Timing is compressed — sandbox payouts transition to `completed` in seconds
* Real OFAC screening runs, but you can trigger deterministic outcomes using specific test beneficiaries
* All authentication, authorization, webhook signing, and state-machine behavior is identical to production
## Next steps
What sandbox is, and how it differs from production.
Checklist for promoting from sandbox to production.