Compare and buy eSIMs with an AI agent
AI agents can compare SimFuse plans with 0 registration steps. Send a traveller to checkout, or use an agent credential to buy with authorized funds. Your assistant's permissions still apply.
Plain HTTP, no SDK to install, no sandbox to apply for. Start with the discovery document and follow the links.
countries and regions, delivered as an eSIM in seconds
registration steps to compare plans and get a checkout link
What answers today
Several ways in, one checkout engine behind all of them. There is no second catalog, no separate price list and no agent-only inventory: an agent buys the same plan at the same live price a traveller does.
- Agentic Commerce Protocol. The full seller API: create a checkout session, update it, complete it. We implement ACP directly rather than through a payment platform's suite, which is what lets us declare our own settlement handler. /.well-known/acp.json
- Universal Commerce Protocol. A shopping service at the same checkout engine, for clients that speak UCP instead. We declare only the checkout capability, because checkout is all we route. /.well-known/ucp
- Product feed. Every plan we sell, priced, with data allowance, validity and destination as structured attributes. Keyless on purpose: a catalog that needs a key to read is a catalog nobody crawls. /agentic/feeds/products
- Trip quote. One keyless GET prices a whole trip: pass the countries and the days in each, and the answer compares one plan covering the route against one per country against a mix, on live prices, with a stated reason and package ids that drop straight into a checkout session. The same trip opens in the planner for a human to see and edit. /agentic/trips/quote
- MCP server. A keyless Model Context Protocol server over Streamable HTTP. Compare plans and coverage, price a trip, and get a link for the traveller to pay on this site. Separate tools open agent checkout sessions and retrieve order status, installation details, usage and top-up options. Private order tools require the buyer's order details. /agentic/mcp
- OpenAPI and Machine Payment Protocol. The machine-readable description of the API, with pricing attached to the operations you can pay for. This is the document to hand a client that discovers services rather than being pointed at them. /openapi.json
- x402 on-chain purchase. One request buys one plan. Ask for a plan, get a 402 quoting the amount in USDC, sign the authorization, retry. Settlement is synchronous, so there is no pending window and nothing to poll. /agentic/x402/purchase/{id}
- Agent registration. How to get a credential, written for a reader that is not a person. Post your agent's name, receive a key, start buying. It is also reachable by following the WWW-Authenticate header on any 401 from us. /auth.md
Who is completing the purchase?
For a traveller paying by card or wallet, get-checkout-link returns the exact plan page without registration or a charge. The API sequence below is for an agent paying with authorized funds. Creating a session does not pay for it.
- Discover. Read the discovery document at our primary domain. It names the API base, the protocol version, the payment handlers we accept and where to register.
- Read the catalog. Page the product feed, or fetch a single plan's price. Ids in the feed are the ids checkout expects, so nothing has to be resolved in between.
- Register yourself. Post a name and get a key back. No form, no review, no waiting. The key lasts a year and is shown exactly once, so store it before you close the response.
- Open a checkout session. Create a session with the chosen plans, then follow its payment and completion instructions. Prices are frozen until price_locked_until. The eSIM is issued after payment settles; creating the session alone buys nothing.
# 1. Find us. Everything else is linked from here.
curl https://simfuse.app/.well-known/acp.json
# 2. Read the catalog. No credential needed.
curl "https://api.simfuse.app/agentic/feeds/products?per_page=5"
# 3. Register a credential for authorized agent purchases.
curl -X POST https://api.simfuse.app/agentic/keys \
-H "Content-Type: application/json" \
-d '{"agent_name":"my-assistant","contact_email":"you@example.com"}'
# 4. Open a session. Payment and completion are separate steps.
curl -X POST https://api.simfuse.app/agentic/checkout_sessions \
-H "Authorization: Bearer $SIMFUSE_AGENT_KEY" \
-H "Content-Type: application/json" \
-d '{"items":[{"id":"<package id from the feed>","quantity":1}],"currency":"EUR"}'Completing the session returns payment instructions for the handler you chose. The full request and response shapes are in the OpenAPI description. https://simfuse.app/openapi.json
Why this works here and stalls elsewhere
Most catalogs are technically reachable by an agent and practically unbuyable. Four things are usually in the way, and none of them is in the way here.
- The product is digital. There is no address to collect, no shipping to quote and no delivery window to promise. An eSIM is provisioned the moment payment settles, which removes most of what makes an agent purchase risky for a seller.
- The credential is self-serve. Registration is an endpoint, not an email thread. That is only safe because the self-serve scope settles prepaid, so there is nothing to charge back and no reason to vet anyone before letting them buy.
- The price is frozen, not guessed. Retail is live and multi-currency, so a quote that drifts between reading and paying is a real failure. Every session locks its prices, and the total is rebuilt from our catalog at settlement rather than read from what the client sent.
- The catalog is open. The feed needs no key, publishes structured attributes rather than prose, and every page on this site is also available as Markdown. An agent comparing options does not have to scrape a storefront to do it.
What your user actually receives
After payment and installation details are ready, get-esim-activation returns the QR code and install links. get-order-status checks progress; check-esim-usage reports usage with a checked_at timestamp. These tools require the order ID and buyer email. Usage and top-up lookups also need the eSIM's ICCID. list-topup-options shows available top-ups; buying one happens in the SimFuse app.
What we are building next
Stated plainly, because a roadmap that reads like a feature list is how you end up trusting a page that was describing an intention. None of the following has shipped.
- A SimFuse app in ChatGPT. Our MCP server is live, but eligibility for a listed ChatGPT integration is unresolved. OpenAI's current commerce rules restrict listings to physical goods and prohibit digital-product or service sales. An eSIM shopping integration needs eligibility clarification before we can promise a listing.
- A Claude connector. A directory listing would make our MCP server easier to find and connect. The listing has not shipped; connection and tool use remain subject to the assistant's supported features and permissions.
- Card settlement for approved platforms. Self-serve keys settle in cryptocurrency, which is what makes issuing them without review defensible. Vetted platforms that need card settlement can already ask, and the handler is declared for the day the rails open to us.
Here for a phone, not an API
Then none of the above matters. Pick a destination, pay, and the eSIM installs before you have finished packing. Browse plans by country
