# Three ways to integrate a post-booking cart

Tag manager, hosted page, or API. The three routes into a post-booking cart, what each one asks of your engineers, and how much control each one leaves you.

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.

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.

[Diagram: A tag manager drop-in launches fastest and gives you the least control over the experience, a hosted page sits in the middle on both counts, and the API gives you the most control for the most build effort. All three reach the same cart.]

Effort against control, and the same cart at the end of all three.

## 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](/docs/gtm), 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](/docs/integration) sets out the flow end to end
and the [API reference](/docs/api) 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](/platform/security-and-compliance).

## Work out which route fits your next quarter

Tell us what your front end looks like and who owns it, and we will tell you which route we would start with.

[Talk to us](mailto:hello@departcart.com)

## 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.