One search across every provider you hold. One cart that spans them. One checkout that books them all.
The spec is public and needs no key.
Where you hold a direct NDC agreement, that carrier is sourced from it and not asked of the GDS at all. The GDS covers everything you have no direct deal with. One list, and each carrier reaches it through exactly one channel, so 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.
Adding a supplier does not change booking logic, and provider connections are configured per partner — so the mix in your result list is yours, not ours.
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.
Hotel, flight, event or car, each item carries the
provider it came from and its own id — so it
is removed and serviced on its own, without touching another
supplier’s hold.
One sum per currency, no grand total. Adding EUR to USD means inventing an exchange rate and quoting a number nobody will be charged.
Reading a cart names the items that can no longer be checked out. Stale inventory is a required field, not a surprise at payment.
All three are in the public spec. 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 verify without asking anyone for a key is harder still. Events ride in the same cart; shopping and cancelling them through the public API is wired per partner rather than published.
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.
Shopping, holding and selling a trip across suppliers, end to end. A new item type is an adapter onto the same cart and the same checkout, not a second flow.
Endpoint by endpoint, it is all in the documentation.
Built and running internally, published here as each one reaches the sandbox spec. If you need one of them for a pilot, say so and it moves up.
| Booking modification | Change a booked item without cancelling and rebooking it. October 2026. |
|---|---|
| Event search | Events already ride in the cart; shopping them through the public API follows the supplier set each partner draws on. |
| Travel policy and approvals | Running, and configured per partner against your own rules and approver hierarchy rather than exposed as one fixed public contract. |
Everything else on this page is in the specification today.
The assistant travellers use in WhatsApp and Telegram is an endpoint like any other here, and the storefront is one of its clients. Type at it and it searches and hands the criteria back, so your storefront runs the same search in its own session and the traveller selects from offers it can actually put in the cart.
So an embedded assistant is not a blank page and a spec. It is a screen in the sandbox you can open and use, then build your own against the same endpoints or keep the one that is there.
One thread, wherever the traveller is. What they had with you in WhatsApp is what they find on the web, and the cart is the same cart. No model to run, no prompts to write, no inference bill — and the conversation never decides what gets booked, because the search it fires runs on the same deterministic engine as everything else here.
You issue the token, we verify it. No account created, no password held, no second login for your customer.
SSO, your own IdP, or server-to-server API keys occupy the same adapter slot.
One deterministic Rust core, everything around it an adapter. Integration is a configuration question, not a rebuild.
| Adapter | Running today | Configured per partner |
|---|---|---|
| Providers | 15+ connected — GDS, NDC, bedbanks, merged into one result list | Direct hotel-chain APIs, your own supplier API |
| Authentication | Delegated partner JWT | SSO, own IdP, API keys — configuration |
| Payments | Provider-hosted payment pages; a test card taken in the run, for the sandbox | Your PSP, your gateway, your internal rails, your tokens — the shape you run decides your PCI scope |
| Verticals | Hotels, flights, events and car rental — any number of each, booked in one checkout | Rail, insurance, eSIM connectivity, and anything else with a supplier behind it |
| Corporate controls | Travel policy applied at search and checkout; approval routed to Slack or Teams | Your policy rules, your approver hierarchy, your exception reasons |
| Loyalty | Referral credit redeemed inside the checkout run | Points, cashback and member schemes at checkout |
Bring your own credentials and negotiated rates, or run on ours.
Read by the people who built the engine, not by a queue. Answered within one business day, with credentials for the web sandbox and the API.
The spec needs no key and the bot needs no signup, so read and try before you fill this in. Storefront keys are issued rather than self-served because the sandbox books against our providers’ own sandboxes, and those stay usable only if they are not open to everyone. Test card 4242 4242 4242 4242, any future expiry, any CVC.
That test card is why the sandbox takes card fields in the request at all: one named card, rate-limited, so anyone with keys can drive a checkout end to end without wiring a payment provider first. Production is the adapter slot above — your PSP, your gateway, your tokens, or the provider’s own hosted page. Payment is the part every partner wants done their way, so it is the part we do not fix in the contract.
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.