Plan your eSIM integration

Public eSIM API access is not available yet. This guide helps you prepare an integration brief for an eSIM specialist. Confirm access and obtain the supported API contract before implementing requests or assigning an agent to build the integration.

Identify who buys the service, who uses the device and who pays. A travel purchase may belong to one customer account. An employee service also needs an assignment to a person and an owner who can approve changes.

List the records your application needs to connect: the purchase, the installed profile and its allowance. A recurring mobile service also needs the subscriber's ongoing plan relationship. These are requirements to confirm against the receiving service's contract.

Decide where customers see the selected offer, coverage, validity and published price. Keep the quoted currency intact. Your application must not reconstruct a customer rate from wholesale costs or an estimated currency conversion.

For each purchase, define what the customer sees after acceptance, fulfillment or refusal. Include a lost-response case in the integration brief. Confirm how the API identifies an existing operation before designing a retry that could create another charge.

A completed checkout does not establish that a device has installed or used the service. Keep those outcomes separate in the customer journey.

Choose the supported devices and the person responsible for helping a customer connect. Installation credentials need a private, authorized delivery path. Keep them out of analytics, public examples and support screenshots.

List the information the customer needs after purchase: setup instructions, the purchased plan, allowance observations and a support contact. Confirm which states and observation times the service can supply before designing the status display.

Ask your Bird specialist to confirm the markets, eligible offers, access requirements and published operations for your use case. Obtain the request and response definitions, authorization requirements, retry behavior and supported installation methods.

Once that contract is available, give your coding agent the contract and your application's identity model. Have it trace one purchase through its confirmed outcome and cover a refused request and an uncertain response. Test with an explicitly authorized account and device before offering service to customers.

Preserve permitted campaign context through signup and your application's customer journey. Define which recorded outcome will count as a conversion, such as a fulfilled purchase or verified first use. A campaign identifier on a signup URL alone does not prove that a later purchase was attributed.