RoamworksRoamworks
Talk to sales
SIM packsDigital vouchersSelf-service pointseSIM APIWhite-label eSIMRoamWorks HotspotAPI docs (coming soon)All products →
Travel and tourism
Online travel agenciesAirlinesRail and coachHotels and rentalsTour operatorsTravel agenciesCruise and ferriesCar and camper rentalsAirport retailEvents and fairs
Finance
Currency exchangeTravel insuranceFintech and cards
Business
Corporate travel
Education
Study abroadUniversitiesSchool tripsExchange and au pair
Maritime and crew
Crew managersSeafarer centresYacht crew
Telecom and retail
Mobile operatorsPhone retailersRetail chains
Loyalty and membership
Loyalty programsMember clubs
Nonprofit and humanitarian
NGOs and aid agenciesVolunteer travelAll solutions →
SIM packs at the hotel front deskLabelled SIM packs for group departuresSIM packs at the rental counterSIM packs at the airport tillAll use cases →
Travel and tourismFinanceBusinessEducationMaritime and crewTelecom and retailLoyalty and membershipNonprofit and humanitarianAll industries →
CoverageBrandTalk to sales
Home/Resources/eSIM API buyer checklist
Checklist

eSIM API buyer checklist

The questions to ask before you connect an eSIM API to a booking flow, an app, or a team tool.

Talk to salesAll resources
  • 6 min read
  • Updated 27 October 2026
  • Checklist

An eSIM API is not only a catalogue call. It is the path from a plan choice to a working data connection.

Use this checklist before you sign a contract or start a build. The answers show whether the integration will be simple, or whether the support team will carry the product.

Product and catalogue

  • Can you get plans by destination, data amount, and validity?
  • Does the price include tax and fees?
  • Can you see stock before you show a plan?
  • Can you map a plan to your own product or SKU?
  • Can you hide plans that do not fit your market?
  • Can you show the plan terms, the last date to install, and the validity in days?
  • Does the response include the countries and regions that the plan covers?

A catalogue that changes without a version or a change notice will break your product. Ask how the plan list changes and how much notice you get.

Checkout and delivery

  • Can you create an order with the price the buyer saw?
  • Can you keep your own checkout and payment flow?
  • What happens when the price changes or a plan sells out?
  • How does the buyer get the QR code or install link?
  • Can you show the order status in your own interface?
  • Can you resend the eSIM if the email is lost?
  • Can you cancel or refund an order before the eSIM is installed?

Keep the payment in your own checkout. Do not send card data to the eSIM API. Use the order reference from your system so support can find the sale.

Orders and webhooks

  • Is the order call idempotent with your reference?
  • Which events does the webhook send: order created, paid, eSIM ready, installed, failed, expired?
  • Does the webhook retry after a failure?
  • Can you verify that a webhook came from the API?
  • Can you fetch the order status if a webhook is lost?
  • What is the order timeout, and what happens after it?

A reliable integration does not depend on one webhook. Fetch the status after a delay, and show a clear state in your own product.

Test and launch

  • Is there a sandbox with test plans and test keys?
  • Can you test a sold-out plan, a price change, and a failed install?
  • Can you test the QR code on a real phone?
  • Is there a separate set of live keys?
  • Can you rotate a key without a downtime window?
  • Does the API have a version and a deprecation policy?

Run a test order end to end before you show the product to a customer. Test on more than one phone model.

Errors and support

  • Are the error codes documented with a clear action for each one?
  • Who answers first when a traveler cannot install the eSIM?
  • Can support find an order by your reference and the traveler email?
  • What is the response time for a failed order?
  • Is there a status page or an incident process?
  • Does the API log enough for support without personal data?

A fast API with slow support is not a finished product. Ask for the support path before launch.

Data and privacy

  • Which data does the API need: destination, dates, plan, reference, email?
  • Can you avoid sending card data and identity documents?
  • Is there a data processing agreement?
  • Where is the data stored, and for how long?
  • Can you delete or export the order data?
  • Does the API set cookies or load third-party scripts?

The ICO guidance gives a useful data checklist. The PCI DSS standard applies to the payment side, not to the eSIM order.

Service levels and operations

  • What is the uptime target, and how is it measured?
  • What is the latency target for the plan and order calls?
  • Is there a rate limit? What happens when you reach it?
  • Can you see usage and errors in a report?
  • What is the incident process, and who contacts whom?
  • Is there a plan for a network or provisioning outage?

Put the target and the support path in the agreement. A marketing page cannot carry a service level.

A simple test plan

  1. Create a test order for one destination.
  2. Check the price and the currency.
  3. Open the order status and the QR code.
  4. Trigger a price change and a sold-out case.
  5. Install the eSIM on a real phone.
  6. Ask support to find the order by your reference.

If the last step is slow, the integration will be slow in production.

Sources and checked

  • PCI Security Standards Council, PCI DSS, checked 27 October 2026.
  • Information Commissioner's Office, UK GDPR guidance and resources, checked 27 October 2026.
  • RoamWorks API notes, checked 27 October 2026.

The eSIM API page walks through the calls, the webhook, and the steps from test keys to live keys. Talk to us about the integration on the contact page.

Start
Put travel data in your product.

Tell us where you meet the traveler and what you sell today. We will send the model, coverage list, and integration notes.

Talk to salesExplore the API