Skip to content
Provider-neutral by design

Global connectivity, delivered as infrastructure

One API for eSIM provisioning, coverage, usage and settlement across mobile networks — with a console your team and your partners can actually operate.

Console preview
Active eSIMs
1,284

connectivity_esims

Orders
312

console_orders

Provisioning success
99.2%

provider_operations

Webhook delivery
99.9%

console_webhook_health

Provisioning and usage
Operations settled and usage events received

GSMA

eSIM profiles

SM-DP+ activation, LPA strings, ICCID

TADIG

Network identity

MCC / MNC, operator-level coverage

OpenAPI 3.1

Published contract

Generated from the running service

Double-entry

Settlement ledger

Idempotent, balance-constrained

About Nesoraa

Infrastructure, not a storefront

Mobile connectivity is sold down a chain of suppliers, each with its own contract, its own identifiers and its own idea of what an error means. Nesoraa absorbs that and gives you one contract, one set of identifiers, and a record you can reconcile against.

Provider-neutral

Suppliers sit behind an adapter port. Application code depends on the port and never on a vendor, so a second supplier is an adapter rather than a rewrite.

Safe to retry

Every write is idempotent and every provider call settles exactly once. A timeout on your side cannot become a duplicate eSIM or a double charge on ours.

Reconcilable

Balances are a double-entry ledger, not a counter. History is immutable, and a balance always equals the sum of the entries that produced it.

Honest about state

An operation whose outcome cannot be proven is reported as uncertain rather than failed, because "failed" invites the retry that double-provisions.

Platform

Connectivity you integrate once and operate forever

One contract for provisioning, coverage, usage and settlement — with the operational surface that makes it supportable in production.

Provision an eSIMv1
POST /v1/esims
Authorization: Bearer key_live_…
Idempotency-Key: 4f1c…

{
  "country": "DZ",
  "plan_id": "plan_dz_5gb_30d"
}
202 Accepted

{
  "object": "operation",
  "id": "op_7FK2c9…",
  "kind": "provision",
  "state": "pending",
  "esim_id": "esim_3QN8f2…"
}

An API that behaves under retry

Provisioning is asynchronous because the networks behind it are. Every write returns an operation you can poll, every operation settles exactly once, and the states it can be in are published rather than inferred.

  • Provision on demand

    POST an eSIM and poll one operation until it settles.

  • Scoped API keys

    Per-key scopes, separate test and live environments.

  • Idempotent writes

    A retried provision cannot create a second eSIM.

  • Signed webhooks

    Delivery attempts and receiver responses are inspectable.

Built to be operated, not just called

Coverage, orders, operations, webhook deliveries and balances are all first-class objects with their own views — so a support question has an answer that does not start in a log file.

  • Operator-level coverage

    Countries and networks by TADIG and MCC / MNC.

  • Reconciled operations

    Every provider write settles, or is flagged as uncertain.

  • Usage telemetry

    Byte counters and last-observed network per eSIM.

  • Ledger-backed balances

    Double-entry, so a balance always equals its history.

Coverage
DZ

Algeria

Optimum Telecom · 603-02

Available
FR

France

· 208

Coming soon
ES

Spain

· 214

Coming soon
AE

United Arab Emirates

· 424

Coming soon
SA

Saudi Arabia

· 420

Coming soon
FAQ

Frequently Asked Questions

What the platform does today, and what it does not.

Still have questions? We're here to help.

Talk to us
Integration
Test environment
OpenAPI 3.1 schema
Signed webhooks

Put connectivity behindyour own product

Read the contract before you talk to anyone. The schema is published, the state machines are documented, and the console shows what the platform does today.

Provider-neutral
Idempotent writes
Double-entry settlement