Introducing the YonoSIM API (2026): a Developer-First eSIM Marketplace, Live in 15 Minutes

Five things you get with the YonoSIM API

1. One rate — our published retail. Same number a traveler pays on yonosim.com/plans — exposed in the API for you to bundle inside your product. No partner-only markup, no gated discount ladder, no NDA. Volume rebates against retail available on request at ~$10k+/mo — email [email protected]. Live rate table at yonosim.com/developers/pricing hits the API on render — the number you see is the number your integration will pay.
2. Good-faith transactional refunds. If a specific eSIM fails to activate, or an end-customer contacts you unable to use a plan because of a network/provisioning issue on our side, we credit that activation back to your balance — same policy that governs our consumer refunds. Case-by-case support, not a systematic margin lift. Standard support-triggered refunds go through POST /v1/orders/:id/refund; provisioning failures at issue time auto-credit before the order ever confirms.
3. Real-time usage webhooks. order.activated, order.data.low, order.data.exhausted, order.expired, order.refunded — enough to power a top-up upsell at the exact moment a traveler runs out of data.
4. White-label activation page. Partner subdomain, logo, colors. Your customer never sees YonoSIM branding during install unless you want them to.
5. Live in 15 minutes. Waitlist to sandbox key is 24 hours; the playground at api.yonosim.com/docs is open to anyone right now with no signup. First real integration is typically a same-day exercise.

Why now

Travel eSIM demand is up-and-to-the-right — Reddit threads about “which eSIM should I get for [country]” are the single highest-intent buying signal on the whole travel internet right now, and every travel-adjacent product from booking engines to hotel loyalty apps to travel insurance dashboards should probably be selling the eSIM alongside the plane ticket or the room key. Almost none of them do.

The reason is that the API layer for this is bad. Raw wholesale APIs are built for carriers and MVNO integrators — sales-call onboarding, NDA'd pricing, no SDK, no webhooks, no refund story, no support Slack. Retail eSIM stores are built for consumers — you can hit their public site, but there's no API, no white-label activation, no webhooks. Airalo Partners exists in the middle but is contract-gated with a 2–6 week sales cycle and NDA'd discount rates, and Holafly has no partner program at all.

We've been running the consumer side of YonoSIM long enough to know exactly which of those gaps hurts the most. So we built the thing we wished existed when we were shopping for it: a self-serve API that quotes the same rate a traveler already pays on yonosim.com — no partner-only markup, no gated discount ladder — an interactive playground that returns real responses to real curl requests, a good-faith transactional refund policy inherited from the consumer store, and webhooks scoped to the moments in the customer journey where a partner actually needs to know something. Nothing revolutionary — the point is that this has been the missing rung of the eSIM distribution ladder, and nobody had built it.

Try it in 30 seconds

Every endpoint has a Test Request button in the Scalar playground, but if you'd rather just paste, here are working commands against the live sandbox. Real sandbox keys with $10 of test credit are issued via the waitlist form — 24-hour turnaround. The playground uses a demo Growth-tier key with rotating test credit so you can explore without signing up.

curl "https://api.yonosim.com/v1/countries" \
  -H "Authorization: Bearer sk_test_growth_daf7d4add37757f28cb4c9e020b41da3fd0aca463ee0af0b"

curl "https://api.yonosim.com/v1/plans/search" \
  -H "Authorization: Bearer sk_test_growth_daf7d4add37757f28cb4c9e020b41da3fd0aca463ee0af0b" \
  -H "Content-Type: application/json" \
  -d '{"country":"JP","minDataGb":5}'

curl "https://api.yonosim.com/v1/orders" \
  -H "Authorization: Bearer sk_test_growth_daf7d4add37757f28cb4c9e020b41da3fd0aca463ee0af0b" \
  -H "Content-Type: application/json" \
  -d '{"planId":"JC065","customerEmail":"[email protected]"}'

curl "https://api.yonosim.com/v1/orders/ord_RtFSRxfGapnI/usage" \
  -H "Authorization: Bearer sk_test_growth_daf7d4add37757f28cb4c9e020b41da3fd0aca463ee0af0b"

No wrapper library needed to try it — curl and the JSON body are the entire onboarding surface. The npm scope @yonosim/api is reserved (v0.0.1 placeholder shipped today) and the full TypeScript SDK generated from the OpenAPI 3.1 spec lands there alongside the first partner integration. The spec itself is public at api.yonosim.com/openapi.yaml — any OpenAPI code generator will produce a client in the language of your choice in the meantime.

Who this is for

• Travel apps — booking, itinerary, expense, and currency apps that already own the pre-trip surface but leave the eSIM purchase to a fourth-party tab.
• Hotel and PMS marketplaces — attach a destination-scoped eSIM to a room booking; battle-tested at physical kiosk locations already.
• Corporate travel platforms — one policy-controlled data plan issued alongside the flight, expensed on the same card, reported on the same dashboard.
• Travel insurance products — bundle a destination-matched eSIM into the trip-insurance PDF; good-faith refund policy on activation failures means support-triggered cases return the activation to your balance instead of eating margin silently.
• Tour operators — issue a shared regional plan to every guest on a multi-country tour without asking them to download a fourth app.
• Fintech travel perks — credit-card benefits, neobank travel modes, business-card loyalty tiers. Data as a perk reads better than a lounge pass.

One rate. Our published retail. In your API.

Same rate a traveler pays on yonosim.com/plans — exposed via the API for you to bundle inside your product. No partner-only markup. No gated discount ladder. Our retail already sits well below Airalo and Holafly on most routes, so bundled inside your product (where your customer sees your price, not ours) the math works from your first order.

Live sample rates rendered from the API at yonosim.com/developers/pricing — the numbers on that page are pulled from POST /v1/plans/search on render, so what you see is exactly what your integration will pay.

How this compares to the other options

The frame we're trying to occupy is developer-first. Raw wholesale APIs have the supply but treat every partner as a bespoke sales cycle. Retail eSIM stores have the price surface but no partner program. Airalo Partners is the closest analog and is genuinely good once you're in, but the contract cliff before signup means most builders who'd be great customers never make it past the discovery call. We think the honest, direct move is to put the price sheet on the internet and let you decide whether to book time with us.

What's shipped in V1

Every layer below is live in production at api.yonosim.com right now, not on a roadmap slide. This is the actual system a partner integrates against today:

1. Postgres persistence: orders, brandings, webhook subscriptions, delivery attempts, and a full balance ledger — every debit and credit an append-only row.
2. Hashed API-key auth: SHA-256 lookup, per-key balance, per-key tier discount (Starter / Growth / Scale / Enterprise), rotate and revoke via CLI.
3. Real eSIM provisioning: POST /v1/orders issues a real ICCID + LPA against 200+ countries with two-phase saga semantics — the balance debit rolls back automatically if upstream fails, so partners never end up billed for an eSIM that never materialized.
4. Real refunds:POST /v1/orders/:id/refund calls upstream to cancel and credits the activation cost back to the partner's prepaid balance in the same DB transaction.
5. Real usage sync: GET /v1/orders/:id/usage polls upstream for actual byte-level consumption (rate-limited to one upstream call per 30s per order so partners can hammer the endpoint without generating an upstream storm).
6. Stripe prepaid credit:POST /v1/balance/recharge returns a Stripe Checkout URL; the checkout.session.completed webhook atomically credits the ledger with idempotency-key semantics so double-fires don't double-credit.
7. HMAC-signed webhook delivery: lifecycle events (order.issued, order.activated, order.data.low, order.data.exhausted, order.refunded) fire to subscriber URLs with X-YonoSIM-Signature headers, 30s / 5m / 1h / 6h exponential-backoff retry, and a dead-letter table after four failed attempts.
8. White-label activation page: a public HTML page at api.yonosim.com/a/:orderId renders the QR + iOS/Android install steps with per-partner branding (logo, primary color, support email). No partner build required.

Two things are explicitly follow-ups when a partner needs them. The npm scope @yonosim/api is reserved (v0.0.1 placeholder is on npm today so the name can't be squatted); the full TypeScript SDK generated from the OpenAPI 3.1 spec ships there alongside the first partner integration. Custom- domain support for the activation page (esim.yourbrand.com CNAME → api.yonosim.com) is the other. Everything else is real, in prod, being hit today.

How to get access

Two paths, pick the one that matches your patience:

• Try before you talk to a human: api.yonosim.com/docs is open now. Every endpoint has a Test Request button. The playground runs against a shared demo Growth-tier key with rotating test credit; explore without signing up.
• Real sandbox key + Slack: the waitlist at yonosim.com/developers is a 24-hour turnaround. You get a real key, the OpenAPI spec, and (at Growth tier and up) an invite to a private Slack channel with the founding team.

FAQ

Bottom line

The developer tier of eSIM distribution has been a hole in the market for years. Wholesale APIs are built for telco integrators, retail apps are built for consumers, and the one contract-gated partner program in the middle takes weeks to enter. YonoSIM API is the version we wished existed when we were shopping — public pricing, self-serve access, automatic refund built in, real webhooks, and a playground that shows you the response body before you sign anything. If any of that maps to a product you're building, the fastest way to see whether it's a fit is to hit the playground and see what comes back.