Book 30 min
Developer API

One cart. Different suppliers. One checkout.

One search across every provider you hold. One cart that spans them. One checkout that books them all.

Read the docs Get sandbox access

The spec is public and needs no key.

Aggregation

One search. Every provider you hold. One list.

Your direct agreements and every other provider you hold, searched at once and returned as one list. No carrier arrives twice.

One request in, one offers array out. Never split by supplier — every offer is already mapped into one schema before it reaches you.

Fan-out and merge across providers One search — for hotels, flights or car rental — is sent to every provider configured for the partner for that vertical: GDS and direct NDC agreements for flights, bedbanks and chain APIs for hotels, car rental suppliers, and any aggregator the partner already buys from. The results are normalised into one list per vertical. One search hotel · flight · car Flights — GDS and NDC direct Hotels — bedbanks and chains Car rental suppliers Aggregators you already use One merged list per vertical, one schema normalised into one schema before it reaches you

The mix in your result list is yours: your suppliers, your rates, not ours.

What you are not building

Search and book are the easy half.

A GDS record has always been able to hold a flight, a hotel and a car. Booking them is still one segment at a time — no basket, and no single checkout at the end of it. Building that flow is not the fan-out; it is keeping one basket coherent when every supplier in it behaves differently. That is where the months go.

Any mix, one basket

Hotels, flights and car rentals from different providers, any number of each, held together.

One checkout for all of it

Every part is confirmed with its own provider, and the customer always sees what is booked.

Serviced part by part

Cancel one item with its real penalty quoted, without touching the rest of the trip.

A checkout in progress, one of two items booked. The YUL to CDG flight shows a green Booked badge; the B&B Hotel in Paris shows Under review, with a note that payment was sent and the provider has not confirmed yet. The order summary counts two items, one hotel and one flight, totalling USD 1,467.35.
Two suppliers, one checkout. An item the provider has not confirmed yet says so, rather than being quietly counted as done.

Plenty of APIs sell flights. Plenty sell hotels. Finding one where a flight, a hotel and a car from different suppliers check out together is harder, and finding one you can try without asking anyone for a key is harder still.

Reference storefront

The sandbox is the reference storefront.

Every screen in it — search, cart, checkout, saved travellers, bookings, the chat — is built on the endpoints you would call. Not a mockup, and not a demo running on fixtures. Below: a hotel from one supplier and a return flight from another, each keeping its own price breakdown and cancellation terms.

A shopping cart holding two items: a Holiday Inn hotel in Montréal marked non-refundable with base and tax broken out, and a Hahn Air economy return between Winnipeg and Montreal shown as two itineraries with every leg, layover and operating carrier. An order summary panel totals both as USD 743.27, and a cross-sell block below offers events at the destination.
“TravelPortal” is a placeholder brand. The storefront is white-labelled — your name, your domain, your palette.
Coverage

What the API covers

Shopping, holding and selling a trip across suppliers, end to end. New kinds of travel go into the same cart and the same checkout.

Endpoint by endpoint, it is all in the documentation.

Assistant

Want chat inside your own app? One is already wired.

The assistant travellers use in WhatsApp and Telegram, ready to go inside your own app. It already runs as a screen in the sandbox: open it, then keep it or build your own.

One conversation wherever the traveller is, and the same cart. No model to run, no prompts to write, no inference bill.

Authentication

We do not own your customer's identity.

Your customer stays signed in to your app. No second login, no account on our side, no identity stored.

Access

Sign in with Google. Build today.

The web sandbox and the API reference open with a Google sign-in and hand you a sandbox token. No form, no wait.

The spec needs no key and the bot needs no signup. Test card 4111 1111 1111 1111, expiry 12/30, CVC 123.

Ready for your own suppliers and brand? Tell us below and we scope a pilot.

Would rather talk first? Book 30 minutes or write to info@gochattravel.com.

We store what you send only to answer it — see the privacy policy.