Going Live
Move your Partner app from sandbox testing through production certification, pilot access, and general availability.
Move your Partner app from sandbox testing through production certification, pilot access, and general availability.
The one thing that surprises everybody
Nothing carries over from sandbox. Your app, credentials, installs, and webhook secret are all per environment. Production issues a new
client_id,client_secret, andwebhook_secret, and you must register your redirect URIs again against your production callback. Sandbox values fail in production withinvalid_client.
The four stages
| Stage | Who can see your app | What you prove |
|---|---|---|
| Nobody—sandbox only | The whole integration except the handshake (Building in the sandbox) |
| One Monta test operator | The OAuth handshake, end to end, against production endpoints |
| One or more named design-partner operators | The integration against real data, with a customer who agreed to it |
| Every Monta operator | — |
Your app moves between stages when Monta widens its operator allowlist. Monta enforces the allowlist server-side for catalogue visibility and installation, so at stages 2 and 3 operators outside the list cannot see or install your app even if they know its name.
Stage 2: certify the handshake
This is the only part you have not already built in sandbox. Monta issues production credentials, scopes your app to a test operator with synthetic data, and walks the flow with you.
Prepare these items
- Deploy a reachable production
redirect_uriover HTTPS. - Deploy a production webhook endpoint over HTTPS that responds with
2xxwithin 10 seconds. - Set up secure storage for a production client secret and webhook secret.
Demonstrate the flow
- An operator selects Connect in Monta Hub, and your redirect URI receives
?code=…&state=…. - Exchange the code within its one-minute window and store the tokens.
- Call the API with the access token and confirm that it returns the expected data.
- Refresh before the access token's one-hour expiry and persist the newly returned refresh token each time.
- Verify the
install.createdsignature and handleinstall.revoked.
Steps 3–5 are already proven in sandbox. In practice, certification focuses on steps 1, 2, and 4.
Where the flow starts
The operator starts the flow from inside Monta Hub. Do not build a "Connect with Monta" button or construct the authorization URL. Your only inbound surface is your
redirect_uri. This is also why you do not send a PKCEcode_challenge; see the OAuth integration guide.
Stage 3: pilot
Monta adds a real operator who has agreed to be your first customer. Nothing about your app changes; only the allowlist. This stage introduces real charge points, real sessions, and real edge cases, so expect to iterate here.
Watch for conditions that sandbox data cannot show: volume, unusual hardware states, operators with large fleets, and long-tail null values in real records.
Stage 4: generally available
Monta clears the allowlist and lists your app for every operator. Each operator still installs and consents individually—a catalogue listing enables discovery, not access.
Before this stage, Monta reviews your requested scopes again. Expect scrutiny in proportion to the power of what you request: reading charge points is not the same as control-charging or wallet-transactions.
Migration checklist
- Store the production
client_idandclient_secretsecurely; do not use the sandbox pair. - Store the production
webhook_secret; do not use the sandbox secret. - Register and deploy the production
redirect_uriexactly as Monta will call it: HTTPS, exact string match, and no wildcards. - Run a production webhook endpoint over HTTPS that returns
2xxwithin 10 seconds. - Switch token acquisition from
POST /api/v1/auth/tokento the authorization-code exchange. - Switch the API base URL to production.
- Persist the newest refresh token after every refresh-token rotation.
- Handle
403 NEEDS_REAUTHseparately from other403responses. - Stop all use of an install after
install.revoked. - Apply backoff for the default per-install limit of 1,000 requests per 60 seconds.
- Maintain a reconciliation path that does not depend on webhook delivery.
- Remove secrets from sandbox configuration, logs, and CI variables.
Things that stay the same
Reassuringly little changes beyond credentials and hostnames:
- Every endpoint, payload, and scope name
- Webhook event names, payloads, and signature scheme
- Rate-limit semantics, per install
- Error shapes, including
NEEDS_REAUTH
The Partner API authorizes against the install, not against how you authenticated. Sandbox is therefore a faithful rehearsal of everything except the handshake.
Treat production credentials as production credentials
You receive production credentials during your first certification run, before any customer is involved. Treat them accordingly from day one: do not use shared inboxes, log credentials in CI, or reuse them across your own environments.
At this point, your app is scoped to a test operator, which limits the blast radius. The secret itself is still real.
If a secret is lost or exposed, ask Monta to re-issue the client. Re-issuing rotates client_id and client_secret and invalidates the old pair, so plan a brief window to deploy the new values.
Endpoints
| Purpose | Sandbox | Production |
|---|---|---|
| Partner API | https://partner-api.sandbox.monta.com/api/v1 | https://partner-api.monta.com/api/v1 |
| Token acquisition | POST /api/v1/auth/token | Authorization-code exchange at the identity provider |
| Issuer / OAuth base | Not available | Reveal on request |
Getting help
Monta performs webhook replays, credential re-issues, operator-allowlist expansions, and sandbox lifecycle events for you. Please contact us.
Updated 2 days ago