Going live
What switching from a sandbox environment to production invalidates, in what order to change it, and the checks that gate the switch.
Moving an integration from a sandbox environment to production changes more than one credential. Everything below is scoped to the environment, so all of it becomes invalid at once.
What the switch invalidates
| Thing | Why it breaks |
|---|---|
| API key | Keys belong to one environment permanently. There is no promoting a key |
| Application id | Different per environment |
| Webhook signing secret | Endpoints are per environment, each with its own secret |
| Plan references | Recreated by hand in production — nothing copies them across |
| Stored subscription ids | A sandbox subscription id means nothing in production |
| Base URL | Only if your host differs |
The stored-ids one causes the most damage. Any subscription, customer, or payment id you have persisted from sandbox testing is meaningless after the switch. Have a relink script ready before you cut over, not after you discover the mismatch.
The four go-live checks
Throttle gates the switch and returns a requirements array naming exactly what failed, so you never have to guess:
| Requirement | Means |
|---|---|
subscription_active | An active or past-due subscription, or partner status |
production_provider_connection | An active processor connection in the production environment |
application_exists | At least one application in the workspace |
production_terms_recent | Production terms accepted within the last 5 minutes |
The five-minute window on terms acceptance catches people. Accepting terms and then going to fix a missing connector invalidates it. Sort everything else out first and accept last.
Order of operations
- Set the live credentials — API key, application id, webhook signing secret, and base URL if it differs.
- Recreate plan references in production and verify the amounts. A typo here charges real customers the wrong figure.
- Register the webhook endpoint and subscribe it to every event you handle.
- Confirm nothing is missing with
GET /api/v1/webhook-endpoints/coverage— it lists event types that were emitted with no subscriber. - Run your own verification script, and confirm it reports production. A script still pointed at sandbox will pass cheerfully.
- Do one small real transaction and watch it land in your database.
- Convert existing accounts.
- Relink stored subscription ids.
- Enable plan gating last, once nobody can be stranded in a blocked state.
Two things that hide a failed cutover
A failed build leaves the previous image serving. The app stays up, healthy, and running old code — so a fix you merged may simply not be live. Check the deploy status for your merge commit before concluding the code is wrong.
Verify a fix using behaviour unique to that change. It is easy to confirm a deploy by testing something that actually shipped two releases earlier. Pick an assertion only the new code satisfies.
After you are live
- Sandbox environments keep working. They stay on sandbox provider credentials, so you can keep testing against a live workspace.
- Losing entitlement freezes production, it does not delete it. A cancelled or unpaid subscription sets the production connector inactive; re-subscribing reactivates it. See Payment connectors.
- The first renewal is the only path you could not test. It arrives about a month later with nobody watching. Diarise it.
For the full build sequence, see Billing your SaaS app and its checklist.
Last updated August 9, 2026