Authentication & environments
Every request authenticates with an API key sent as a bearer token:
curl https://api.sandbox.interglobe.io/v1/me \ -H "Authorization: Bearer ig_test_your_key_here"The environment is in your key
Section titled “The environment is in your key”InterGlobe has two environments, and the key prefix decides which one you hit — there is no separate
?env= flag to forget:
| Prefix | Environment | Base URL | Network |
|---|---|---|---|
ig_test_ |
Sandbox | https://api.sandbox.interglobe.io/v1 |
Mock rail — no real spend |
ig_live_ |
Production | https://api.interglobe.io/v1 |
Tier‑1 network |
Sandbox and production data are structurally isolated — a ig_test_ key can never read or write
production data, and vice versa. Build and test entirely in the sandbox, then swap the key to go live.
Keys are shown once
Section titled “Keys are shown once”When a key is created it is returned once and stored only as a hash — we can never show it to you again. Store it securely (a secrets manager, not source control). If you lose it, roll a new one.
Scopes
Section titled “Scopes”Keys carry scopes (for example esims:provision, bundles:write, webhooks:manage). A call that needs a
scope your key doesn’t have returns 403 with a machine‑readable error and a doc_url. Self‑serve sandbox
keys come with the full developer scope set so you can exercise the whole API.
Idempotency
Section titled “Idempotency”Every mutating request (POST/DELETE) accepts an Idempotency-Key header. Send a unique value per logical
operation and retries are safe — the same key returns the original result instead of acting twice. See the
idempotency guide.