Trip Sync
It reads your itinerary so you find out on the sofa, not at the gate.
Almost every coverage problem a traveller has is a problem of timing rather than of coverage. The information you needed was available. It was available on a Tuesday evening when you were booking, and you discovered you needed it on a Saturday morning in an arrivals hall with no signal. Trip Sync exists to move that discovery to the Tuesday.
The two ways in
The first is a calendar connection. You authorise Google Calendar or iCloud with a read only scope, pick which calendars are in scope, and we watch for events that look like travel: a flight number, an airport code, an airline name, a hotel booking with a city on it. Nothing else is touched.
The second is a forwarding address. Every account gets one, in the shape [email protected]. You forward the confirmation email from the airline, the rail operator or the hotel, and about 20 seconds later the trip appears in the app with every leg parsed out. Mail arriving from an address that is not on your account is dropped before it is parsed, so a leaked address cannot be used to inject trips into your account.
Use one, use both, or use neither. None of this is required for the eSIM to work. The Passport still installs once and still recognises a country by itself. Trip Sync is a head start, not a dependency.
What a parsed trip looks like
Here is a real multi country itinerary run through it, of the kind that looks simple on a booking site and is not.
| Leg | Countries involved | Status | What we tell you |
|---|---|---|---|
| London to Zurich, 4 Mar | Switzerland | Covered | Swisscom then Sunrise, 5G on both |
| Zurich to Milan by rail, 7 Mar | Italy plus 40 minutes of Switzerland | Covered | The train crosses a border you did not book. Both sides are in your balance |
| Milan to Tirana, 11 Mar | Albania | Check | Covered, but the pack you were about to buy is Europe only and excludes it |
| Tirana to Istanbul, 14 Mar | Turkey | Covered | Turkcell first. Registration rules apply to handsets, not to eSIM profiles |
| Istanbul, 6 hour layover, 17 Mar | Qatar | Flagged | Your ticket says Istanbul to Bangkok. It routes through Doha and you will want data there |
Two rows in that table are the entire point. The Zurich to Milan train is sold as a journey between two cities and is in practice 40 minutes of Swiss network followed by Italian network, which matters if you bought a single country pack. The Doha layover is not printed on the ticket in any way a human reads, because the ticket says Istanbul to Bangkok, and six hours in Hamad International is exactly when you want a working connection.
The three awkward cases
The unlisted layover. Ticketing systems hide the routing behind a single origin and destination pair. We resolve the flight number to its actual routing and tell you which extra countries you will physically stand in, along with how long you are there. Under 90 minutes we say so and suggest you do nothing, because you will spend it walking.
The land border. Rail and coach routes across Europe, Southeast Asia and South America cross borders that nobody books. A day trip from Vienna clips Slovakia. A bus from Chiang Rai clips Laos. Wallet balance covers all of them, which is the main reason we recommend balance over single country packs on any trip with a train in it. If you already hold a country pack, we tell you which hours of your journey it does not cover.
The cruise. This is the case where we lose, and we say so plainly. A ship at sea is not in any country, and no travel eSIM anywhere covers open water. Your connection stops somewhere between 12 and 20 nautical miles from the coast. On board you are on the ship's own satellite service, billed by the ship, at a price we have no control over. What we do is list the ports, confirm coverage in each one, and tell you where the signal ends so the moment it dies is not a surprise you interpret as a fault.
19 s
median time to first byte on landing with the profile pre staged
3
event fields read, and no others: title, dates, location
145
destinations checked against your route, 200 plus at launch
What we read, and what we never read
A feature that reads a calendar has to be specific about what that means, because the vague version of this sentence is how permissions get abused. Here is the whole list.
| Field | We read it | We never read it |
|---|---|---|
| Event title | Yes | |
| Event start and end date | Yes | |
| Event location field | Yes | |
| Attendees and their email addresses | Never | |
| Event description and notes | Never | |
| Attachments and meeting links | Never | |
| Calendars you did not connect | Never | |
| Anything in your inbox you did not forward | Never |
Three more commitments. The scope we request is read only, so the write ability is absent rather than merely unused. Deleting a parsed trip deletes the itinerary and the source it came from in the same action, with no soft delete and no retention tail. And none of it is sold, shared with a partner or used to target advertising, because we sell gigabytes and have no advertising business to feed.
What it changes on the day
The night before you fly you get one notification. It names every country on the route, the coverage state of each, the carriers you will be on, and the single recommended purchase if you need one. If you need nothing, it says you need nothing, which is a notification most travel apps are structurally incapable of sending.
On landing, the profile for that country is already staged, so your phone attaches to the right carrier ordering instead of scanning for one. You can check what a given country looks like before you connect anything at all on coverage, browse what is live on destinations, and buy the balance that makes a multi border trip simple in the store.