eSIM and mobile connectivity FAQs

Offer travel data, recurring mobile plans or employee connectivity. Connect the offer, purchase, installation and ongoing service in a customer journey your business can operate.

An eSIM is the digital profile used by the device. A package or subscription defines the service: its coverage, allowance, included calls and messages, validity and price.

Coverage and service capabilities belong to the selected offer. Review the included destinations and network terms rather than relying on a global label.

Define an embedded API or branded hosted journey around your customers and commercial model. Connect plan discovery, checkout, installation, management and support.

Use a mobile offer that explicitly includes those services and a supported porting path. Do not infer them from a data package or the presence of a reported number.

Explore the eSIM workspace for a technical evaluation. Speak to a connectivity specialist about your markets, plans, billing model, distribution and employee rollout.

No. A data package can provide internet access without normal mobile calls or SMS. Check the specific plan’s included services; use a mobile plan when the customer needs a number and calling service.

Follow the package’s activation and validity rules. Installation and first network use are different events, and the point that starts the allowance period belongs to the plan terms.

Use the compatible offers for that profile. A top-up must match the allocated service and its supported package behavior; another package in the catalog is not automatically compatible.

This product is designed for businesses offering or managing connectivity. Start with a specialist to define the travel proposition, destination coverage and customer journey.

They serve different jobs. A recurring mobile service renews over billing periods and can include a number, calls and SMS. A travel package supplies a defined allowance and validity for a trip.

Portability depends on the market, number and providers involved. Confirm eligibility and the required account information before scheduling the move.

Included services belong to the offer. Present data, voice and SMS separately and do not infer mobile calling simply because a profile reports a phone number.

Define the audience, network service, plan terms, customer requirements, billing and support model with a specialist. Validate the complete subscriber lifecycle in that market before expanding distribution.

Yes. Model the employee’s continuing mobile service and each travel package according to their own terms. The appropriate combination depends on the employee’s market, device and plan eligibility.

No. Connectivity and device management serve different purposes. Keep your device policy, application controls and access management in place.

Number ownership and transfer eligibility depend on the arrangement and market. Define that policy before onboarding and use the appropriate transfer or porting process.

Bring the employee markets, device mix, existing contracts, expected travel, billing structure and HR or IT integration. Start with a representative group and verify setup, support and offboarding.

An embedded service can keep the customer journey, branding and plan management within your product. Define the commercial and operating arrangement explicitly; a referral alone does not provide that lifecycle.

Plan an API integration around your existing experience and payment arrangement. Agree the responsibilities for plan pricing, billing, identity and customer support before implementation.

Define the entry and return paths as part of your integration. Preserve the customer’s intended action and acquisition context without placing installation credentials in analytics or public URLs.

The supported markets, plan types, checkout and billing model, identity requirements and the amount of subscriber self-service you own. Prototype the full purchase-to-first-use journey before estimating only the API calls.

Use a supported same-device installation path when available, with QR or manual setup as a fallback. The exact options depend on the device, operating system and provider.

The plan determines the activation trigger and validity period. Explain those rules before installation; do not apply one assumption across every package.

Check the provider’s recovery rules first. Removing a profile can make recovery harder and does not itself cancel the underlying service.

It means the system does not have that observation. Keep the state explicit and help the customer verify setup rather than inferring success or failure from missing data.

Usage timing depends on the network and service. Show the latest observation time and treat an unavailable update as missing information, not zero use.

No. Use the compatible offers returned for that allocated profile. Coverage overlap alone does not establish compatibility.

The offer’s validity and stacking rules determine what happens. Present the effective terms of the new package before purchase.

Follow the existing order to its outcome when a response is uncertain. Use the documented request identity and recovery behavior for your integration instead of creating another purchase blindly.

Eligibility depends on the country, number type and providers involved. Confirm the supported porting path before accepting a customer commitment.

Follow the porting procedure for the service. Keeping the donor line active is commonly necessary; an early cancellation can prevent a successful move.

Timing depends on the market, donor provider, required information and the request outcome. Use confirmed scheduling information and communicate changes rather than promising a universal duration.

No. A mobile subscription and an application messaging sender have different purposes and eligibility. Use the mobile plan’s porting process for a subscriber’s phone service.

No. An order can be fulfilled before the device installs or uses the profile. Keep purchase, installation and network observations distinct.

Available actions depend on the plan, allocated provider, state and workspace authority. Present the capabilities of that service rather than a universal set of controls.

Give it the relevant information and a bounded set of authorized actions. The service owner must enforce access and report the outcome; the assistant’s wording does not establish that a change completed.

Find the existing order, financial record and provisioning evidence. Resolve that attempt before creating a replacement that could charge or allocate another service.

No. A useful integration also covers offer discovery, purchasing, fulfillment, service state and ongoing management. Installation credentials are one private part of that lifecycle.

An agent can work from the current API description, task guides and your application. Have it inspect the supported operations and demonstrate a controlled complete journey; do not assume a method exists from a marketing example.

Keep the original request and order identity, then use the documented recovery behavior to establish its outcome. Starting a fresh purchase can create another charge or service.

Record the business outcome you intend to optimize, such as a completed purchase or verified first use. Preserve acquisition context through the relevant handoff and join it to that outcome without including private installation credentials.