Ask "does this eSIM provider have an API?" and you will get a lot of yeses. Ask "can an AI agent complete a purchase from it, on its own, without a human at the keyboard?" and the yeses mostly evaporate. The two questions sound similar and are not. The first is about whether software exists; the second is about whether an autonomous buyer can get all the way from "I need data" to "here is your working eSIM" without falling into a step that assumes a person.
That second question is the one that matters if you are building an agent, and it is rarely answered honestly because the answer is usually no. So rather than rank brands, this is a test you can run yourself. Five steps. A provider has to pass all five for an agent to actually buy from it; most pass one or two.
The test: can the agent get all the way through?
Walk the five steps a purchase requires and ask, at each one, whether a program with no browser and no human helper can complete it.
- Can it read the catalogue without a browser? Prices and coverage have to be available as data — a public API, a catalog endpoint, an
llms.txt— not locked inside a JavaScript storefront that only renders for a human eye. - Can it start without a signup? If the first thing required is an account — an email to confirm, an OAuth flow to click through — an agent with no inbox and no browser is stuck before it begins.
- Can it pay without a human at a card form? Card-on-file checkout assumes a person typing a number into a page tied to a session cookie. An agent needs a rail it can actually complete: a balance it holds, a stablecoin transfer, an agent-payment protocol — something that is not a form.
- Can it receive the eSIM as data, not as a QR emailed to a person? Delivery has to come back through the API as an identifier plus activation surfaces the agent can use — a QR image URL, a raw payload, a one-tap install link — not a code mailed to a human to scan with a phone camera.
- Can it be trusted, not just be able? Technical capability is not enough. Without spending caps, scopes, and a kill switch, "an agent can buy this" really means "an agent can drain this," and no one should wire that up. Bounded autonomy is the difference between a demo and something you would actually let run.
How the landscape actually scores
One caveat before the categories: this market moves quickly, and providers add capabilities. Treat what follows as a way to classify, not a permanent verdict — and re-run the five steps yourself before you rely on any of it.
Mainstream consumer marketplaces
The household names — Airalo, Holafly, Nomad, Saily, Ubigi and the rest — are built, well, for consumers. The catalogue lives in an app or a JavaScript storefront; buying wants an account or a saved card; activation is a QR code meant for a phone camera. Several offer partner or B2B APIs, but those sit behind a signed agreement and an approval process aimed at companies, not at an individual agent wiring something up this afternoon. On the five-step test they typically clear step 1 only partially (a gated B2B API is not the same as a public one) and fall at signup, the card form, and the absence of any agent spending model. They are excellent at what they were designed for, which is a human at a checkout. The Roamzy vs Airalo comparison walks one of them through the test in detail and is candid about where the incumbent still wins.
Privacy and crypto eSIMs
A second category — Silent Link, Surfroam and similar privacy-leaning services — solves the payment step that trips up the mainstream, by accepting crypto, and sometimes loosens the signup requirement too. That gets them meaningfully closer on steps 2 and 3. But they are still, for the most part, human-facing web checkouts: no public agent API or MCP server to drive the flow programmatically, and no spending-cap-and-kill-switch model for delegated autonomy. Closer on the rail, still not built to be driven by a program.
The agent-native cohort
A third, much smaller and newer category is building for agents on purpose — a public API or an MCP server as the front door, not an afterthought. Roamzy is in it; so are early efforts like eSIM.dog and eSIM Copilot. This is the only category where passing all five steps is even on the table, because the flow was designed for a non-human buyer from the start rather than retrofitted onto a consumer store. It is also tiny and early — a handful of names, not a mature market — so the honest framing is "this is where to look," not "this is solved."
Running the test on Roamzy
Since this is our publication, here is Roamzy against its own five steps, including where it is weak. No grading on a curve.
- Read the catalogue without a browser — yes. A public REST API with an OpenAPI spec, a catalog endpoint with open CORS, an llms-full.txt written for engines, and an MCP server with twelve tools available both as an npm package and a remote endpoint you connect to by URL.
- Start without a signup — yes. Anonymous-first: the agent calls one endpoint, gets a session, and can price and buy with no account. Identity is opt-in afterwards. This is the single biggest barrier most providers never remove.
- Pay without a card form — yes, with an honest asterisk. Payment is in USDT or USDC on the network of your choice, so there is no card form in the loop. The asterisk: a user with no crypto wallet is genuinely worse off here than at a card checkout, and the native on-chain agent-payment rails everyone is excited about are not wired up yet — that needs a treasury and is deliberately parked. What works today is a payment link the user settles from any wallet.
- Receive as data — yes. The order response returns a phone number plus three activation surfaces: a QR image URL, the raw QR payload, and a one-tap install link, so it works whether or not the agent and the phone are the same device.
- Be trusted, not just able — yes, and this is the point. Every token carries daily and monthly caps, a cool-off ceiling on new tokens, a big-transaction confirmation gate, and three independent kill switches; anonymous sessions are held tighter than named ones. The developer guide covers the model.
Two more honest notes. The OAuth identity layer is built and published, but because of how connectors behave today it mostly goes unused — most agents connect anonymously, by design. And the agent-native category Roamzy sits in is weeks old, not years. What Roamzy can claim is the fullest current combination of the five — anonymous start, crypto rail, per-MB billing with no expiry, programmatic delivery, and a real spending model — not that it is alone in the category or that the category is finished.
What makes the combination matter
Any one of these can be found elsewhere. Crypto payment exists at the privacy eSIMs. A public-ish API exists at the B2B tier of the marketplaces. The point is that an agent has to pass every step in one continuous flow — and a chain breaks at its weakest link. A provider that nails payment but forces a signup fails. One with a great API but a card-only checkout fails. One that passes the first four but has no spending caps should not be wired up at all. Agent-readiness is not a feature you can have most of; it is the whole sequence or it is nothing. That single-flow constraint is why the case for connectivity as an agent's first purchase rests on doing all five, not four.
Run it yourself
The five questions are short on purpose. Point them at any eSIM provider — including this one — and you will know within a few minutes whether an agent can actually buy from it: can it read the catalogue without a browser, start without a signup, pay without a card form, receive the eSIM as data, and be bounded by a real safety model? Most of the market answers no to three or more. The ones that answer yes to all five are worth your integration time. To see what a yes looks like end to end, the five-minute setup tutorial walks the whole flow, and agents.html is the one-page overview.