Sandbox and live

Every account has two environments. They share a host and a code path, and they share nothing else — separate databases, separate balances, separate keys, separate orders.

	Sandbox	Live
Key prefix	esf_test_ci_	esf_live_ci_
Balance	Test credit	Real money
eSIMs	Test profiles, not installable on a phone	Real, installable
Who can create keys	Owner, Admin, Developer	Owner and Admin only

The key selects the environment

The URL is the same for both. The prefix on your credential decides which environment you reach.

# Sandbox — same host
curl https://partner-api.esimfo.com/v1/balance \
  -H 'Authorization: Bearer esf_test_at_...'

# Live — same host
curl https://partner-api.esimfo.com/v1/balance \
  -H 'Authorization: Bearer esf_live_at_...'

This removes an entire class of accident. A staging deployment that accidentally points at the production host still cannot spend real money, because it is holding a sandbox key.

The corollary matters too: switching to live is a credential change, not a URL change. If your config has a base URL per environment, you are managing the wrong variable.

What sandbox is for

Sandbox is where you build and where your CI runs. Orders complete, webhooks fire, balance moves, errors behave the same way.

The eSIMs it returns are structurally real — a QR code, an LPA string, usage counters — but the profiles are not installable on a device. Test your plumbing there, not your handset.

Ids do not cross over

A package_id from sandbox does not exist in live, and neither do order or eSIM ids. Anything you hard-coded from sandbox will return not_found in live. Re-read the catalog per environment.

Moving to live

1. Have an Owner or Admin create a live key in the portal.
2. Grant it only the scopes you actually call.
3. Swap the credential in your secret store — leave the URL alone.
4. Re-read the catalog and drop any cached sandbox ids.
5. Place one small real order and confirm it end to end.

The full checklist is in Going live.