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, and webhook_secret, and you must register your redirect URIs again against your production callback. Sandbox values fail in production with invalid_client.

The four stages

StageWho can see your appWhat you prove
  1. Sandbox
Nobody—sandbox onlyThe whole integration except the handshake (Building in the sandbox)
  1. Certification
One Monta test operatorThe OAuth handshake, end to end, against production endpoints
  1. Pilot
One or more named design-partner operatorsThe integration against real data, with a customer who agreed to it
  1. Generally available
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_uri over HTTPS.
  • Deploy a production webhook endpoint over HTTPS that responds with 2xx within 10 seconds.
  • Set up secure storage for a production client secret and webhook secret.

Demonstrate the flow

  1. An operator selects Connect in Monta Hub, and your redirect URI receives ?code=…&state=….
  2. Exchange the code within its one-minute window and store the tokens.
  3. Call the API with the access token and confirm that it returns the expected data.
  4. Refresh before the access token's one-hour expiry and persist the newly returned refresh token each time.
  5. Verify the install.created signature and handle install.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 PKCE code_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_id and client_secret securely; do not use the sandbox pair.
  • Store the production webhook_secret; do not use the sandbox secret.
  • Register and deploy the production redirect_uri exactly as Monta will call it: HTTPS, exact string match, and no wildcards.
  • Run a production webhook endpoint over HTTPS that returns 2xx within 10 seconds.
  • Switch token acquisition from POST /api/v1/auth/token to the authorization-code exchange.
  • Switch the API base URL to production.
  • Persist the newest refresh token after every refresh-token rotation.
  • Handle 403 NEEDS_REAUTH separately from other 403 responses.
  • 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

PurposeSandboxProduction
Partner APIhttps://partner-api.sandbox.monta.com/api/v1https://partner-api.monta.com/api/v1
Token acquisitionPOST /api/v1/auth/tokenAuthorization-code exchange at the identity provider
Issuer / OAuth baseNot availableReveal on request
📘

Getting help

Monta performs webhook replays, credential re-issues, operator-allowlist expansions, and sandbox lifecycle events for you. Please contact us.



Did this page help you?