Choose an eligible offer, prepare private installation and follow one purchase through first use and ongoing support. Leave with a release-readiness record for your own customer journey.
Your relationship. Their next connection
Bring useful mobile connectivity into a product customers already turn to, on a trip, every day, or at work.
Worked scenario: Alex Lee · Your mobile service. The following is an illustrative application workflow, not a live result.
- Choose. Alex selects a connectivity offer inside your branded experience. The offer defines the coverage and allowance. Observable state: Offer selected.
- Install. A compatible, unlocked device follows the installation steps. Your product keeps the subscriber oriented. Observable state: Compatibility confirmed.
- Activate. The example customer tests mobile data on the intended line in coverage. Provider activation remains a separate, possibly unknown observation. Observable state: Example data observed on device.
- Stay useful. Usage and service information give Alex a reason to return to your product. Ongoing options depend on the offer. Observable state: Usage in view.
What this changes
- For your customer: Connectivity within a familiar product experience.
- For your business: A way to extend a travel, everyday, or employee service.
- For your team: A defined subscriber journey from installation to ongoing support.
Before you call it complete
Confirm each observable state in your own integration. The application must establish the business outcome separately from a successful API request or delivery event. Exercise the relevant unsuccessful case in the product’s working example and follow its technical references.
Decide which service you can actually support
Start with workspace setup and the integration guide. Use the supported operation contract for the selected offer to connect purchase, installation and ongoing service.
Worked example: Fieldnotes wants to offer a customer-paid travel data pass inside a booking journey. The fictional request is Spain, seven days and 10 GB, on a known unlocked eSIM device. Those quantities are requirements, not a current Bird offer or quote. The application owns the traveler and booking; the purchase owner records the accepted offer and financial result; support joins that purchase to its allocated profile and dated device observations.
- Inspect the current catalogue and selected offer with an authorized owner. Record every destination, network terms, validity, activation trigger, allowance, currency and published amount. Check hotspot, roaming and included services explicitly. An itinerary covering Spain and Japan cannot pass on a Spain-only answer; leave Japan unknown and hold that itinerary until confirmed.
- Check the exact model and market variant, supported OS and carrier lock. A familiar device name is insufficient. Record the intended data line and the supported installation method. Use the compatibility worksheet and device and coverage instructions.
- Identify buyer, device user, payer and care owner. For the travel example, one customer approves the purchase. For a company-funded employee, record the assignee, manager approval, company budget and IT support separately. Unknown employee entitlement blocks purchase even if the device is compatible.
- Decide the first release boundary. This example is a prepaid data service. Do not assume recurring renewals, mobile voice/SMS or number porting are orderable. Evaluate those requirements with the specific service owner before promising them.
Decision: prepare one authorized Spain data pilot after offer, access and device evidence are confirmed. Hold the Japan extension and any employee assignment without an approver. Keep price and network coverage unquoted until the current offer supplies them.
Follow one purchase to its actual outcome
- Before purchase, keep the customer acceptance, selected offer/revision, amount/currency and application reference together. Obtain the supported request, authorization and retry contract from Bird; this guide supplies no public purchase endpoint.
- In an authorized test, submit one intended purchase. Retain its idempotency identity and original order reference. A stale quote requires reviewing the new offer and customer acceptance, not silently accepting another amount.
- Separate accepted, charging, provisioning, pending, completed and failed. A funding wait is not fulfillment. The funding requirement describes the total wallet balance required, not simply a shortfall. Even a response completed within the request needs its actual status inspected.
- If the response is lost, recover the original order before creating another purchase. Preserve the same logical retry identity under the supported contract. Do not let a browser refresh, delayed status read or support retry create a second charge.
- On fulfillment, confirm the intended profile/package and accepted terms. On failure or cancellation, reconcile the financial result separately, including any pending refund evidence. Nothing about an accepted checkout proves that a phone has connected.
Worked uncertainty: O-310 loses its response
The fictional application saved O-310's purchase identity, then lost the response. It displays “Outcome unknown; checking the original purchase.” Support later finds the original order completed with profile S-310 and the intended package. It continues to private setup for S-310. It never places O-311 merely because the first browser request timed out. If the original order is still pending, the result stays pending; if it failed, show that result and investigate its financial closure before a separately authorized replacement.
Use the embedded connectivity journey to assign application responsibilities and the service investigation procedure to reconcile order and billing evidence. Rehearse the uncertain-purchase case in the illustrative connectivity example; it makes no purchase.
Install privately, then test the connection
- Confirm fulfillment, an installable profile, authorized access to credentials and working internet for setup. Record the selected offer's activation trigger before installation: do not consume validity early by guessing.
- Use the eligible supported iOS link or private manual activation material. A supplied QR can be shown on another screen where the approved flow supports it. Android installation links and Bird-hosted QR URLs are not currently supplied by the checked contract. Never expose activation credentials in public links, analytics, screenshots or unrestricted support chat.
- Follow device prompts, label the profile, select the intended mobile-data line and apply the offer's roaming/network instructions. Keep the original profile reference in the support record.
- At a covered destination, test mobile data on that line and record device evidence and time. If voice or SMS is included in a separately eligible offer, test it separately. Profile installed, device data observed and provider activation reported are different facts.
A fulfilled package can still fail installation
O-310 is fulfilled, but the issuing carrier cannot return credentials. Keep the order fulfilled and setup blocked; the authorized support owner retries the credential read under supported policy. Buying again does not repair that read. If the device rejects installation, record model/variant, OS, method, step and redacted error. Check recovery and reinstall eligibility before deleting a profile.
Installed does not mean connected
After installation, a device reports no data. Check the selected line, carrier lock, destination coverage and supplied roaming/network settings. Retest the included service with support. Until then, record “installed; first use unverified.” A later successful handset data test becomes a dated device observation; provider activation and usage can still be unknown. An empty usage meter is not a zero-balance reading.
Use the maintained installation procedure and the installation journey. Continue unresolved cases through service support, with safe references rather than credentials.
Keep care useful after first use
Read allowance with its observation time, package state and expiry. Missing or stale usage is not a reported zero. A top-up must be compatible with this allocated service; matching geography alone is insufficient. Confirm its current terms and activation/stacking behavior, approve one purchase and follow that original order to the attached package. A delayed balance update must not trigger another purchase.
For employee departure, IT owns company access removal while the service owner separately confirms supported termination or transfer, final charges and any number obligations. Closing an app account does not establish service closure. Assign an unresolved-case owner until all obligations have evidence. See employee responsibilities and usage and top-up operations.
Build the complete path
Copy this release-readiness worksheet into your pilot record. Fill evidence and owners before offering service to customers; it is a planning record, not an API payload.
Customer need / buyer / device user / payer:
Application, purchase, installation and support owners:
Access confirmation / supported contract / date:
Offer / revision / quote / amount / currency / accepted terms:
Itinerary / coverage / validity / activation trigger:
Model / market variant / OS / unlocked evidence:
Private setup method / authorized credential access:
Original purchase identity / order / profile / package:
Financial status and time / fulfillment status and time:
Installation result / redacted failure / recovery owner:
First-use device observation and time / provider observation:
Allowance / observation time / freshness / compatible top-up:
Unknowns / stop conditions / escalation / follow-up date:
Authorized tester / normal and failure evidence / launch decision:Filled decision for the fictional pilot
Scope: one customer-paid Spain travel pass. Application owner: booking team; purchase owner: commerce team; installation/support: connectivity care. O-310 was recovered without a second purchase; package fulfilled. The first credential read failed; private setup later succeeded. Device data was observed at 10:20 UTC in the example; provider activation and usage remain unobserved. Japan coverage and current commercial quote are unresolved. Decision: hold customer launch until the current access, offer and authorized normal/failure device test are recorded. These are invented teaching observations, not Bird service results.
Carry the record to an eSIM integration specialist. Start workspace setup. Use the getting-started checklist to prepare the decision before any authorized real test.
Connect the next step
- Offer to first use: retain the purchase, installation and observation boundaries.
- Coverage: verify every itinerary destination.
- Employee assignment: distinguish payer, user and departure obligations.
- Usage and compatible top-ups: keep timestamps and pending purchases visible.
- Quote worksheet: calculate only from confirmed terms.
Your application owns the customer relationship and business actions. Preserve the appropriate identity, consent, and outcome when you move between products.
Questions to resolve
Does fulfillment prove first use?
No. Fulfillment, installation, device-observed data and provider observations are separate evidence.
Should an uncertain response cause another purchase?
No. Recover the original operation and financial result first. A replacement requires a distinct supported decision and authorization.
Go deeper in the documentation
- Integration planning: access and supported contract.
- Device and coverage: exact variant and destination.
- Installation: private setup and recovery.
- Operations: order, service and support evidence.
- Usage and top-ups: dated allowance and eligible packages.