Environments
Sandbox and production, and what differs between them.
Every project has two environments. A key belongs to one, so there is no request where the environment is ambiguous.
| Sandbox | Production | |
|---|---|---|
| Key prefix | aux0_test_ | aux0_live_ |
| Accounts | Fixtures that behave like real ones | Real accounts |
| Sends | Go nowhere | Go to the provider |
| Webhooks | Fire normally | Fire normally |
| Billing | Never | Accounts and calls are metered |
| Rate budgets | Simulated, so you can test the queued path | The provider's real windows |
Sandbox accounts
A sandbox project starts with a set of connected accounts across every provider, including the unhappy ones: an account mid-backfill, one whose app password was revoked, one disconnected. They are there so you can build the handling for those states without waiting for one to happen.
You can also drive a sandbox account into a state:
curl https://api.aux0.com/v1/accounts/acc_test_gm/simulate \
-H "Authorization: Bearer $AUX0_TEST_KEY" \
-d '{ "event": "password_changed" }'That fires the real account.needs_attention webhook with the real payload,
so your handler is tested against the same bytes production will send.
Switching
The dashboard keeps the environment in the query string (?env=sandbox), so
every screen is linkable in either one and switching keeps the page you are
on.
What does not differ
The API surface, the response shapes, the event payloads, the error codes and the signing. If something works in sandbox and fails in production, the cause is the provider or the account, not aux0 — which is what makes the sandbox worth trusting.