Skip to main content
Moving from Sandbox to Live changes your credentials and your endpoint’s expectations of you. The API surface is identical.

​
Checklist

  1. Complete business verification in the dashboard. Live keys cannot be generated before it is approved.
  2. Know your egress IPs. Live keys require an IP allowlist (1 to 32 addresses or CIDR ranges). See IP allowlist.
  3. Generate Live keys (dashboard, Live, Credentials, Generate keys), then Download .env. Save the six values once. See Generating keys.
  4. Configure your production environment with the six live values. Keep them in a secret manager; never in source control or a client bundle.
  5. Upgrade the SDK to @ensc/sdk 0.4.0 or later. 0.4.0 introduced the conversions API; earlier versions call endpoints that no longer exist, and versions before 0.3.0 send plaintext requests the API refuses.
  6. Register your production webhook endpoint and verify deliveries against the public key at GET /v1/.well-known/ensc-public-keys.json. Send a test event from the dashboard or with ensc.webhookEndpoints.sendTest(id); a Live endpoint accepts only synthetic.test_event. Handle every event type listed in Conversions, in particular conversion.requires_manual_review and payout.failed.
  7. Run one read and one write against Live before routing traffic: for example ensc.banks.list() and a small ensc.conversions.create({ type: 'crypto-issue', chain: 'celo', ... }) that you sign, broadcast and report with ensc.conversions.events.confirmed(). Fund the wallet with a little native gas token first.
  8. Switch the chain slug. Sandbox conversions run on celo-sepolia; Live conversions run on celo. The chain id in every unsigned transaction changes with it (see Environments).
  9. Set up rotation. Decide who holds the dashboard access that can rotate and revoke, and rehearse a rotation on Sandbox: rotate, deploy the new value, confirm, let the old key expire after 24 hours.

​
Sandbox vs Live

A test key can never touch live resources and a live key can never touch test resources (ENSC_TEST_LIVE_MISMATCH, or ENSC_INVALID_CHAIN when a live key names a testnet). Everything else about the two environments is in Environments.

​
Operational expectations

  • Idempotency keys on every write. Your retries then can never double-execute. The SDK does this by default. See Idempotency.
  • Clock accuracy. Signatures and sealed responses are time-bound to 5 minutes; run NTP on the servers that call ENSC.
  • Handle ENSC_RATE_LIMITED (429) by backing off. The limits: 600 requests per minute and 10,000 per hour per key; 600 per minute per source IP on every route; 60 per minute per key on writes to the conversion, account-resolution and transfer routes; 120 per minute per source IP on the public routes (the key document, the OpenAPI documents and the reference page). A request body may be at most 1 MiB. See Rate limits.
  • Watch expiresAt on rotated keys (signingKeys.list(), apiKeys.list(), encryptionKeys.list()) so a rotation is completed inside its 24-hour window.
  • Pin X-ENSC-API-Version. The SDK pins 2026-09-15. Read the changelog before adopting a newer version.

​
If a credential leaks

Revoke it in the dashboard immediately (revocation takes effect within seconds), generate a replacement, deploy. Because responses are sealed to your signing key and writes need your encryption key, a leaked API key alone does not expose data or enable writes, but treat any leak as a rotation of all three secrets.