Move to production

Go-live checklist

1. Top up your live balance in the portal. An order with an empty balance fails with insufficient_funds.
2. Create a live key and store it server-side. Keep the sandbox key working in your staging environment.
3. Send an Idempotency-Key on every order request, derived from your own booking reference.
4. Register a live webhook URL and verify signatures before trusting a payload.
5. Persist our order ID and eSIM ID against your booking, so you can re-deliver a QR code without re-ordering.
6. Handle the five order outcomes: completed, invalid_request, insufficient_funds, provider_error and a network timeout.
7. Alert on wallet.low_balance so you never fail an order for funding reasons.

What we guarantee

• Issuance is synchronous. POST /orders returns only once eSIMs exist, or once the order has failed and you have been refunded.
• Money is debited before the profile is allocated, and refunded in full inside the same request if issuing fails.
• An idempotency key can never produce two orders. Replays return the original order with Idempotent-Replay: true.
• Plan validity starts when the traveller's device first attaches to a network, not at purchase.
• Usage figures come from the network and are typically no more than 15 minutes behind.
• Webhooks are retried up to three times with backoff, and every attempt is visible in your portal.

How API changes are communicated

The path carries the major version. Inside `v1` we only make additive changes: new endpoints, new optional parameters and new response fields. Breaking changes ship as `v2` and the previous version keeps running for at least six months. Everything is listed in the changelog, and material changes are emailed to your account contact.