Skip to content

Platform

The life of an eSIM order

What happens between a partner choosing a plan and their customer using data — and what NESORAA does at each step so that a slow network, a retry or a supplier change does not cost anyone money.

Five steps, one contract

The same steps run whether the order comes from the partner portal or the API.

  1. 01

    Choose an offer

    GET /v1/offers

    Lists the plans your account can sell — destination, data allowance, validity and your price. The portal shows the same list by country.

  2. 02

    Place the order

    POST /v1/esims

    Send an Idempotency-Key with the offer. The request returns 202 Accepted with an operation to follow; the order is charged to your wallet.

  3. 03

    Provisioning

    GET /v1/operations/{id}

    The supplier creates the eSIM. The operation moves from pending to executing, and ends succeeded, failed — or uncertain, when the supplier has not yet confirmed the outcome.

  4. 04

    Hand over

    GET /v1/esims/{id}

    The eSIM carries its QR code and activation details. In the portal, revealing them is a logged action, so you can see who handed over which eSIM.

  5. 05

    Usage and lifecycle

    GET /v1/esims/{id}/usage

    Data used against the allowance, activation and expiry dates, and the last network seen where the supplier reports it. Suspend, resume and disconnect where the supplier supports them.

Order states that tell the truth

Networks are slow and sometimes silent. An order that has been sent but not confirmed is reported as exactly that.

StateMeaning
pendingAccepted and queued.
executingSent to the supplier.
succeededThe eSIM exists and is yours.
failedNothing was created. The charge is reversed.
uncertainSent, not yet confirmed. Checked again automatically — never treated as failed and re-ordered.

Every order request takes an Idempotency-Key. Repeating a request with the same key — after a timeout, a crash or a network drop — returns the first result instead of creating a second eSIM or a second charge.

Signed webhooks

Your system hears about every change instead of polling for it.

Delivery you can verify

Each delivery is signed with HMAC-SHA256 using your endpoint's secret. A receiver that is down is retried 13 times over about three days, so a weekend outage does not lose events.

Delivery you can inspect

Every attempt is recorded with your receiver's response. A failed delivery can be replayed from the portal or with POST /v1/webhook_deliveries/{id}/replay, and secrets can be rotated without downtime.

eSIM events

  • esim.provisioned
  • esim.provisioning_failed
  • esim.activated
  • esim.suspended
  • esim.resumed
  • esim.disconnected
  • esim.refunded

Money and access

The controls a finance lead and a security reviewer ask about.

Prepaid wallet
Topped up by bank transfer quoting your reference. One wallet per currency.
A ledger, not a counter
The balance is the sum of its entries. Every credit, charge and reversal is listed in your transaction history.
Test and live keys
Test keys never reach a supplier and never move money. Switching to live is a different key, not a setting.
Scoped API keys
Each key carries only the permissions it needs, and can be revoked on its own.
Team roles
Invite colleagues with a role that limits what they can see and do in the portal.
Multi-factor sign-in
Authenticator apps and passkeys for portal sign-in.

Tell us where your customers travel.

We reply by email with the plans available for those destinations and how to start.

Contact salesAPI reference
How the platform works — Nesoraa