Travel eSIM revenue specifically reached $1.8 billion in 2025, up 85 percent from the year before, the figure that actually carries the growth argument for a UK OTA, fintech, or connectivity reseller. The broader eSIM device-connections figure gets quoted more often, eSIM connections are forecast to grow 30 percent in 2026 to 1.5 billion devices, but that growth is driven predominantly by IoT deployments, connected logistics, energy, and smart street lighting under the GSMA's SGP.32 standard, not by consumer smartphones or travel devices. On the UK regulatory side, figures cited by KPMG's analysis of Ofcom market data show UK MVNOs gained 1.5 million customers in 2024 while traditional mobile network operators lost 54,000, a shift KPMG attributes to MVNO competition generally and frames eSIM as a still-nascent factor it expects to accelerate switching further, not as the cause of the 2024 numbers. For a UK-based OTA, fintech, or connectivity reseller, growth in this category is only reachable through the technical layer underneath it: the API.

A hosted reseller portal is enough to sell a handful of destination plans a month. It is not enough to embed connectivity into an existing checkout flow, a wallet app, or a booking confirmation screen, which is what most UK buyers searching for an eSIM reseller API are actually trying to build. The portal assumes the customer wants a new storefront. The API assumes the customer already has one and wants to add connectivity to it.

This guide covers the technical architecture behind an eSIM reseller API, what a production integration actually requires, and how to get from sandbox to go-live without the timeline most teams budget for it.

Monty Mobile's eSIM Reseller Portal includes a full REST API alongside the hosted portal, so a technical buyer is never limited to the storefront.

Technical Context: What an eSIM Reseller API Actually Provides

An eSIM reseller API gives programmatic access to the same infrastructure a hosted reseller portal presents through a browser: profile ordering, activation, plan configuration, and lifecycle management, exposed as REST endpoints instead of screens. The underlying mechanism is the GSMA's Remote SIM Provisioning architecture defined in SGP.22, which governs how a profile is prepared, downloaded, and activated on a device without a physical SIM swap. The API does not replace this architecture. It is the integration surface a reseller's own systems use to trigger it.

The distinction that matters for a technical buyer is between an API that exposes the full provisioning lifecycle and one that only exposes plan purchase. A purchase-only API lets a platform sell a plan but still redirects the customer to a hosted activation page, which breaks the in-app or in-checkout experience the integration was meant to preserve. A production-grade API handles profile ordering, device compatibility checks, QR code or activation-code delivery, and webhook-based activation confirmation, all within the reseller's own interface.

The Gap Between a Reseller Portal and a Production Integration

Most eSIM wholesale programs were built portal-first, with an API added afterward as a secondary access method rather than designed as the primary interface. This shows up in predictable ways during technical evaluation: sandbox environments that do not reflect production behavior, rate limits that were never load-tested against real booking-flow traffic, and documentation that describes endpoints without documenting failure states.

For a UK OTA or fintech evaluating providers, the evaluation criteria that actually predict integration success rarely appear in a sales conversation: sandbox fidelity, rate limit architecture, webhook reliability, and API versioning policy. A provider that cannot answer specific questions about webhook retry behavior or how breaking changes are versioned has usually not run enough production integrations to have needed answers to those questions yet.

API Architecture: Endpoints, Sandbox, and the Integration Flow

A production eSIM reseller integration follows a consistent sequence regardless of the specific provider: authenticate, query available plans for a destination, order a profile, deliver the activation method, and confirm activation through a webhook.

Core endpoints

The minimum viable eSIM reseller API surface covers plan and coverage lookup by destination, profile ordering against a selected plan, activation status polling or webhook subscription, and device compatibility checking. Some providers expose additional endpoints for usage tracking and top-up ordering, relevant for platforms offering plan renewal rather than single-trip sales only.

A sample profile order request looks like this:

The response returns a profile identifier and, depending on delivery method, either a QR code payload or an activation code the reseller's front end presents to the customer.

Sandbox access

A sandbox that only simulates successful responses is close to useless for integration testing. A usable sandbox reproduces failure states, an invalid EID, an unsupported destination, a rate-limit breach, so the reseller's error handling is tested before go-live rather than discovered by a customer in production.

Activation confirmation via webhook

Polling for activation status works for low volume but does not scale to booking-flow traffic. A webhook that fires on activation, delivery failure, or profile expiry lets the reseller's own system update a booking or order record without maintaining a polling loop.

A sample activation webhook payload:

Travel OTAs and Booking Platforms: API Integration at Checkout

A UK travel platform integrating eSIM at the post-booking confirmation screen is optimizing for attach rate at the moment of highest traveler intent, which means the integration needs to be fast and needs to work without redirecting the customer away from the confirmed booking.

Destination-based plan resolution

The API should return the correct plan automatically based on the booking's destination data, rather than requiring the customer to search or select a country manually, since every added step at this point in the flow reduces conversion.

Sub-second response requirements

A checkout-embedded eSIM offer needs a plan lookup response fast enough not to introduce a visible delay in the booking confirmation flow, which rules out providers whose plan catalogue query is not built for real-time lookup.

See Monty Mobile's Retail and eCommerce solutions for how destination-based checkout integration is typically structured.

Digital Wallets and Fintechs: Embedding Connectivity Without Leaving the App

A fintech or digital wallet integrating eSIM through an API is protecting a specific outcome: the customer never sees a third-party brand or interface during purchase or activation.

Native activation flow

An API-only integration, with no hosted fallback page, is what lets a wallet present the eSIM purchase and QR code entirely within its own app, since any redirect to a provider-hosted page breaks that experience and introduces a visible seam in an otherwise native product.

iOS and Android SDK support

A provider offering native SDKs on top of the REST API reduces the engineering effort of building device compatibility checks and QR rendering from scratch, though the SDK should be optional, not the only integration path, for teams that prefer to build directly against the API.

Independent Developers and Connectivity Resellers: Building on the API Directly

A smaller technical reseller without a large engineering team still benefits from API access over a portal-only relationship, primarily for automation: bulk order processing, integration with an existing e-commerce platform, or a custom storefront that a hosted portal cannot replicate.

The tradeoff for this buyer is development time against portal simplicity. A well-documented API with client libraries in common languages closes most of that gap, which is why documentation quality is as much a purchase criterion as the API's functional coverage.

Deployment Example: UK Travel Platform API Integration From Sandbox to Go-Live

A UK-based travel booking platform processing bookings across European and North American destinations wanted to replace an affiliate-link eSIM offer with a native checkout integration, targeting a launch window ahead of the summer travel period.

Sandbox integration began with authentication and a plan-lookup test against the platform's top 15 destination markets, followed by webhook endpoint configuration and a full order-to-activation test cycle in the sandbox environment, including deliberately triggered failure states.

The engineering team completed backend integration in two weeks, covering plan lookup, profile ordering, and webhook handling, followed by one week of QA against the platform's actual destination mix before go-live.

Post-launch, the platform's eSIM attach rate at checkout increased measurably over the prior affiliate-link baseline, with the destination-matching logic removing the manual plan selection step that had been the largest drop-off point in the previous flow.

Note: This is an anonymized deployment scenario based on typical implementation outcomes. Specific results vary by implementation, audience quality, and market conditions.

Compliance Requirements for eSIM Reseller API Integrations in the UK

Disclaimer: the compliance summary above is general guidance, not legal advice. UK consumer law and data protection obligations depend on the specific service model and customer base; confirm current requirements with UK counsel before launch.

See Ofcom's own announcement on the handset-locking ban, and Monty Mobile's Remote SIM Provisioning infrastructure page for the certified provisioning layer this API sits on top of.

Getting Started: eSIM Reseller API Integration

1. Sandbox access request. Request sandbox credentials and confirm the sandbox reproduces both success and failure states before writing integration code against it.

2. Core endpoint integration. Build against plan lookup, profile ordering, and activation confirmation first; treat usage tracking and top-up ordering as a second integration phase if needed.

3. Webhook configuration and testing. Configure the activation webhook and test it against deliberately triggered failure states, not only the happy path, before relying on it in production.

4. Go-live and destination expansion. Launch against a limited destination set first, confirm delivery and activation rates match expectations, then expand the plan catalogue to the platform's full destination mix.

API access is one of three integration models for eSIM B2B connectivity. For how it compares to white-label storefronts and full wholesale reseller relationships, see also: eSIM B2B Platform: Choosing the Right Connectivity Model for OTAs, Wallets, and Resellers.

About the Author

Daniel Dib is Senior Brand Manager at Monty Mobile, a global telecom solutions provider with 25+ years of MNO relationships across 200+ countries. He leads go-to-market strategy and content across Monty Mobile's CPaaS, A2P Wholesale SMS, and Travel eSIM product lines.

Frequently Asked Questions

What is the difference between an eSIM reseller portal and an eSIM reseller API?

A reseller portal is a hosted, browser-based interface for selling eSIM plans, suited to lower-volume resellers who do not need a custom front end. An eSIM reseller API exposes the same provisioning capability as REST endpoints, letting a business embed eSIM purchase and activation directly into its own app, website, or checkout flow rather than sending customers to a separate portal.

How long does an eSIM reseller API integration typically take?

A backend integration covering plan lookup, profile ordering, and webhook-based activation confirmation typically takes two to four weeks for a team with prior API integration experience, followed by a QA period against the platform's actual destination mix before go-live. Timeline depends heavily on sandbox fidelity and documentation quality.

Does an eSIM reseller API require a native mobile SDK, or is REST enough?

REST API access alone is sufficient for most integrations, including web-based checkout flows. A native iOS or Android SDK is useful when a team wants to avoid building device compatibility checks and QR code rendering from scratch, but it should be optional rather than required, since some teams prefer to integrate directly against the API.

What data does an eSIM reseller API integration process, and what are the UK compliance implications?

A typical integration processes device EID, activation timestamps, and destination or plan selection data, which falls under UK GDPR and the Data Protection Act 2018 when linked to an identifiable customer. Resellers should confirm the wholesale provider's data processing terms and document the lawful basis for processing before launch.

This article reflects Juniper Research's eSIM and travel eSIM forecasts (late 2025 to early 2026), KPMG's analysis of Ofcom Q1 2025 market data, GSMA SGP.22, and UK consumer and data protection law as of mid-2026. Recommended review trigger: updated Juniper or GSMA forecasts, Ofcom or ICO guidance changes, or an SGP.22 revision.