Sandbox → production
Going live happens twice: once for your platform, when accreditation issues your production key, and then once per agent, as each is switched to the production environment. The two are deliberately separate — promoting your platform does not move a single agent.
Your platform is promoted once: KYB, review, accreditation, production key. Each agent is then promoted individually, keeping its DID while its AID is re-signed for the production environment. Nothing transacts on mainnet until both have happened.
Platform readiness
Your account moves through five states. Sandbox works from the second one onward — you can build the entire integration before submitting a single document.
| State | What it means | Sandbox | Production |
|---|---|---|---|
EMAIL_PENDING | Account created, email not yet verified | No | No |
PROFILE_PENDING | Verified. Sandbox key issued; company profile incomplete | Yes | No |
KYB_PENDING | Profile complete, documents not yet submitted | Yes | No |
IN_REVIEW | Documents submitted, under review | Yes | No |
ACCREDITED | Approved. Production key available | Yes | Yes |
Sandbox access is never gated on KYB. Your engineers integrate against a full protocol implementation while your legal team assembles documents — the two run in parallel by design, not by exception.
Business verification
Accreditation requires a document set covering the legal entity and its control structure. Submit them from the dashboard; review is manual.
| Document | Purpose |
|---|---|
| Certificate of incorporation | The entity exists and is registered where you say it is |
| Proof of registered address | Where the entity is legally seated |
| Director identification | Who is accountable for the entity |
| Ownership and control structure | Beneficial ownership, for sanctions and AML screening |
Re-submitting a required document type supersedes the current one in any state, so a rejected document is corrected by uploading a replacement rather than by opening a case. Supporting documents append rather than replace.
platform.verification_decided is the one event with no good polling
alternative — it gates everything downstream. Register a
webhook endpoint before submitting so the
decision reaches your systems without someone refreshing a dashboard.
Promoting your platform
Promotion is synchronous and atomic: one call, one response, no polling and no provisioning state to track.
curl -X POST https://api.nustro.com/v1/platform/promote \
-H "Nustro-Api-Key: nustro_sandbox_••••" \
-H "Idempotency-Key: 3f81c2d4-77ab-4e19-9f02-5c8ad61be44a"{
"environment": "production",
"promoted_at": "2026-08-11T09:12:44Z",
"live_key_issued": true,
"api_key": {
"raw_key": "nustro_live_…",
"key_prefix": "nustro_live_9b41",
"environment": "production",
"warning": "Store this key now — it is never shown again."
}
}The production key appears in this response and nowhere else. Promotion is
not repeatable — a second call returns 409 already_promoted with no key,
and the only recovery is rotating the production key. Send an Idempotency-Key
so a timeout after commit replays the original response rather than costing you
the credential.
Promotion issues a key. It does not migrate agents, create production markets, or fund anything.
Environment is not network
These are two independent settings, and conflating them is the most common misconception about going live.
| What it is | Set by | Values | |
|---|---|---|---|
| Environment | Which Nustro namespace the agent belongs to — which key manages it, which counterparties it can verify against, which webhook endpoints receive its events | Promotion | sandbox · production |
| Network | Which chain a given market settles on | Market configuration | Testnet or mainnet, per market |
Promotion moves an agent into the production namespace. It does not choose a chain. A production agent whose market is configured on a testnet settles on that testnet — a legitimate setup for staged rollouts, and for partners who are live on your platform but not yet moving real value. Moving to a mainnet is a separate market-configuration change.
Promoting agents
Each agent is switched individually, which is what lets you go live with one low-risk agent before moving the rest.
| Carries over | Does not carry over |
|---|---|
| DID — the identifier is stable across environments | Escrow balance — scoped to environment and network; it is funded again in production |
| Agent rating and history — the record follows the agent | Markets and wallets — production markets are configured separately, on whichever networks you choose |
| Scope — spend limits, floors, dispute terms | Certificate — reissued; the AID is re-signed for the production environment |
Before switching an agent: your account is ACCREDITED, the agent is
ACTIVE, its production markets are configured with the wallets for whichever
networks those markets use, and — for providers and enterprise agents — its
escrow is funded to threshold on those networks. An agent switched with
unfunded escrow lands in FUNDING and cannot yet transact.
Sandbox and production remain fully separate afterwards. A promoted agent’s sandbox identity continues to exist, so your team can keep testing against it while the production agent transacts.
A sandbox agent can never complete a verified transaction against a production counterparty. Environment mismatch fails at facilitation, before delivery — there is no configuration that mixes them.
Going-live checklist
Common errors
| Code | Status | What it means |
|---|---|---|
not_accredited | 409 | Promotion called before review completed. Wait for platform.verification_decided. |
already_promoted | 409 | The account is already on production. Do not auto-retry — the key is gone from this path; rotate instead. |
key_not_provisioned | 409 | A production key was requested before accreditation. |
escrow_below_threshold | 409 | Agent promotion attempted with production escrow unfunded on a configured market. |
market_not_authorized | 409 | The agent has no production market configured for the target network. |