Every integration conversation eventually turns into the same negotiation between two teams. Commercial wants the line live this quarter. Engineering has a roadmap that filled up in March. The route you pick decides which of those two facts has to give.
In short
There are three ways to put a post-booking cart in front of your travellers: a tag manager drop-in, a hosted page you link to, and an API you build against. They differ in how much engineering work you take on and how much control you keep over the experience. All three reach the same cart underneath.
What each route asks of you
| What it asks | Tag manager | Hosted page | API |
|---|---|---|---|
| A change your engineers have to release | No | No | Yes |
| Server-side work at your end | No | No | Yes |
| The traveller stays on your own page | Yes | No | Yes |
| You control the surrounding page | Partly | No | Entirely |
| Fastest route to a first live sale | Yes | Close behind | No |
| Most control over placement and wording | No | No | Yes |
Route one: the tag manager drop-in
You add a tag through the tool your marketing or analytics team already administers, and set it to fire on the pages where a confirmed booking is already on screen. Nothing changes in your codebase, nothing waits for a release window, and the panel appears inside the page your travellers already land on.
What it asks of your engineering team is close to nothing. What it asks of you is a decision about which pages it fires on and a short test pass before you publish. The step-by-step version is in the tag manager guide, and it is short enough to read before a stand-up.
The limit is the obvious one. You are placing a component inside a page you did not design for it, so you get less say over exactly where it sits and how the rest of the page behaves around it.
Route two: the hosted page
You link out to a page we run, presented in your brand. Your own pages are left alone entirely, which is the reason teams pick this route when the front end is old, shared, or governed by someone who is not in the room.
The ask here is a link and a set of brand assets. That is close to the whole of it. In exchange you give up the surrounding page, because the traveller finishes the task somewhere other than your site before coming back.
Route three: the API
Your servers ask us for a link for a given booking, and you decide where that link lives in your own flow. Take it further and you can build your own front end against the same offers, in which case the experience is entirely yours and so is the work.
This is the route that asks real engineering time, and the one that repays it. Placement, wording, timing, and the surrounding journey all become yours to tune. The integration guide sets out the flow end to end and the API reference has the detail your engineers will want in front of them before they estimate anything.
What does not change between them
The parts most likely to worry you are the parts the route does not touch. The offers a traveller is shown are built for the booking in front of them on every route. The cart takes one payment for everything in it, in the currency you already sell in, on every route. What is bought reaches the booking the same way regardless of how the traveller got there, with nobody on your team actioning it.
So the choice in front of you is narrower than it first appears. It is a question about your own front end and your own engineering calendar, not a question about what your travellers end up buying.
How to choose, honestly
Start with the route you can actually ship, not the one that scores best on paper. The most expensive mistake in this category is not picking the wrong route, it is spending two quarters deciding and learning nothing in the meantime.
Because all three arrive at the same cart, the decision is more reversible than it looks. A tag manager start that proves the demand makes a much easier case for engineering time later, and the work you did in the first route is not thrown away when you move.
What happens once you have chosen
Onboarding covers what your team needs before the first call, the brand configuration, and a test pass against sample bookings. The security posture behind all of this, and what a review at your end should look at, is set out on the security and compliance page.
Frequently asked questions
Which route should we start with?
The one you can ship this quarter. The tag manager route asks least of your engineers and the API route asks most, and the value of learning whether your travellers buy in the post-booking window is far higher than the value of picking the perfect route first time.
Are we locked into the route we choose?
No. All three reach the same cart, so moving later is a change to how the traveller arrives rather than a rebuild of what they arrive at. Starting with a tag manager and moving to the API once the line has earned engineering time is a reasonable path.
How much backend work does the API route actually involve?
Your servers ask us for a link for a given booking and put that link where your travellers will find it. Building your own front end on top is optional and is where most of the remaining effort sits. The full detail is in the API reference at /docs/api.
Does the tag manager route need a release from our engineering team?
No, which is usually the point of choosing it. It is a change inside a tool your marketing or analytics team already administers, published on their own schedule. The setup steps are at /docs/gtm.
Can the cart look like our brand on every route?
Yes. Colours, typography, and wording follow your brand on all three. What differs is how much of the surrounding page you control, which is the trade the three routes are really making.