Can I try GoChatTravel without talking to sales?

Yes, two ways, both open. The Telegram sandbox bot at https://t.me/go_chat_travel_sandbox_bot needs no signup and no credentials. The web sandbox at https://sandbox.gochattravel.com is the full reference storefront — search, cross-supplier cart, checkout, saved travellers and a bookings page — and its keys are issued through the request form at https://gochattravel.com/api, normally within one business day. Checkout in either accepts the test card 4242 4242 4242 4242 with any future expiry and any CVC. The OpenAPI specification at https://sandbox.gochattravel.com/api-docs/openapi.json is public and needs no key at all, so the contract can be read before any conversation.

What makes the cart different from other travel booking APIs?

Most travel APIs sell one vertical from one source, and leave the merge and the cart to the integrator. Here a single cart holds hotel, flight, event and car rental items sourced from different provider APIs, any number of each, and one checkout settles all of them. Three properties of that cart are visible in the public specification: every item carries the provider it came from; totals are returned per currency with deliberately no grand total, because summing EUR and USD would mean inventing an exchange rate; and every cart read returns the ids of items that can no longer be checked out. A GDS record has always been able to hold a flight, a hotel and a car, but booking them is still one segment at a time, with no basket and no single checkout at the end.

Does GoChatTravel support corporate travel policy and approvals?

Yes. Travel policy — fare and rate caps, cabin and room class, advance purchase windows, preferred suppliers — is applied while the traveller is still shopping, so an option outside policy is labelled at search time rather than found in a report afterwards. Rules are configured per company, per traveller group or per trip type. A trip needing sign-off is routed to the approver in the Slack or Microsoft Teams channel the organisation already works in, carrying the itinerary and the policy exception; the cart is held pending that decision and checks out on approval rather than being rebuilt. This is the capability that decides whether a travel management company can use the engine at all.

What happens if payment is taken and the supplier does not confirm?

Checkout books a cross-supplier cart as one run and stops at the first item that fails or needs something, so a cart is never silently part-charged. Each provider is charged as its own item books, and card details are used for a single run and never stored. An item whose charge was sent but not yet confirmed by the provider is shown to the traveller as awaiting confirmation rather than hidden behind a spinner, and nothing retries that charge automatically.

What exactly is deterministic about the engine, and why does it matter?

The booking path — availability, pricing, cart state, booking and post-sale operations — is ordinary Rust code. The same input produces the same itinerary at the same price, every time. No language model selects inventory, computes a price or commits a booking. Models are used only to converse with the end user in natural language. If you removed the model layer entirely, the engine would still work; it would simply need structured input instead of a sentence. This matters because a product where a model decides what to book carries a fundamentally different risk profile, and it is the difference procurement teams are actually asking about.

How many supplier integrations does GoChatTravel have?

More than 15 provider APIs are integrated, spanning GDS, NDC, hotel bedbanks and direct supplier connections. A provider-agnostic normalisation layer maps each supplier schema into one internal representation, so one search returns a single merged result list and adding a supplier does not change booking logic.

Can partners use their own GDS and NDC credentials?

Yes. Provider connections are configurable per partner. A partner can bring their own GDS credentials, NDC connections and supplier agreements, or run on GoChatTravel's existing connections. Partners keep their own commercial relationships with suppliers and hold the accreditation their inventory requires, which is what keeps the margin and the customer on their side.

Which chat channels are supported?

WhatsApp, Telegram, Slack, Microsoft Teams, Facebook Messenger and Instagram Direct are live. Other messengers, and an embedded chat inside a partner's own application, are added on request. The Telegram sandbox is open to anyone without signup; access to the other channels is arranged on request.

White-label booking engine

One engine. Any interface. Any provider.

Chat is one way to shop. A web form is another. Both sit on the same engine: one search across every supplier you hold, one cart across them, one checkout. Your brand, your contracts, your prices.

Book 30 minutes Or try the sandbox first

Read the spec now, no key. Try the bot now, no signup. Keys for the full storefront come by request: its inventory runs on our providers’ own sandboxes, and we keep those working for the people using them.

No key
Read the whole API contract before you talk to us: 15+
Provider APIs we already speak, including the one you are on: 6
Chat channels live, plus your own app: 3
Pilot places open this quarter

The actual product

This is a real cart, not a mockup.

Partners run around 5,000 bookings a quarter through it, and 64% of those carts hold more than one item. We cannot tell you whose they are: the engine is white-label, and naming them would remove the thing they bought.

A traveller assembling an itinerary across several messages, then removing an item from the cart and having the total re-derive. Live inventory, real prices, real booking references.

We would rather show one unretouched screenshot than a page of illustrations. Open the sandbox and put the same flow through it yourself.

Open the sandbox

Keys from the request form, or open it in Telegram with none. Test card 4242 4242 4242 4242, any future expiry, any CVC.

A chat conversation showing a two-item cart — a WestJet flight from Winnipeg to London and a Hampton by Hilton hotel — then the flight being removed and the cart recalculating to the hotel alone. — Cancelling quotes the real penalty before you commit — in the same place the trip was booked, with no phone call in the loop.

A traveller's bookings list holding items from several suppliers, with a cancellation dialog open on a WestJet flight. It states the fare is non-refundable, that the refund would be USD 0.00 against a cancellation fee of USD 228.55, that changes are not allowed, and that the action cannot be undone. — Cancelling quotes the real penalty before you commit — in the same place the trip was booked, with no phone call in the loop.

Three ways in

One engine. You choose how much of it you touch.

The same deterministic Rust core underneath all three. What changes is how much of the interface is yours.

The API

You own the interface. We aggregate your providers into one result list, then handle the cross-supplier cart, booking and post-sale.

Your NDC carriers direct, the rest from the GDS, one list
Public OpenAPI spec, no key needed to read it
Hotels, flights, events and car rental in one cart
Checkout, bookings and cancellation in the same contract
The chat assistant itself, as an endpoint
Your auth, or delegate ours
For teams with their own front end

API overview →

Reference storefront

The sandbox is a working storefront built on that same public API — every screen in it is a call you can make. Brand it and ship it rather than build from nothing.

Every screen is a documented API call
Multi-item cart across suppliers
Checkout, saved travellers and a bookings page
Your brand, your domain
For sellers who need a site, not a spec

Chat channels

Fully turnkey. We configure the channel, the branding and the providers; nothing for your team to build.

WhatsApp, Telegram, Slack, Teams, Messenger, Instagram
Live and taking real bookings
Your suppliers and rates, or ours
For sellers with no engineering to spare

What changes for you

You are not buying inventory. You are buying a shop to sell it in.

A channel you cannot currently sell in

Today that thread ends in a link to your website, and most of them never come back. With the engine behind it, it ends in a booking.

One cart, the whole trip

Three hotels, two flights, a car and an event, from different suppliers, in one basket, checked out together. Any number of items, and the basket is not fussy about what they are: if you sell it and it has a supplier behind it, it goes in the same cart.

Your contracts, your prices, your margin

Your credentials, your rates, your customer. The commercial relationship stays yours end to end.

As much engineering as you want, including none

Turnkey: nothing to design, nothing to integrate. Or take the API and build your own front end. Your developers are in the critical path only if you put them there.

You have already paid to acquire this customer.

The margin is rarely in the first booking. It is in the hotel beside the flight, the car, the event, the insurance. Attach rates stay low anyway, and rarely because of intent. There is no basket open, and no conversation to offer into.

A confirmation page gives you one moment. An email gives you an open rate. Neither knows the trip is eleven weeks away, and neither can ask a question.

A conversation does not close. The trip context is already in it, so an offer needs no form and no second round of acquisition spend. And because the cart is already there, the distance between yes and paid is one tap.

Every one of those is margin on a customer whose acquisition cost you have already written off. That is the whole argument.

Is this you

This lands hardest when four things are already true.

Customers already message you

A WhatsApp number, a Telegram channel, a Messenger page, or chat in your own app — with real traffic in it. We add selling to a conversation that already happens.
You have inventory, or a reason to sell ours

Your own contracts and negotiated rates, connected as they are. Or no supply of your own, and you sell on ours.
Someone owns the number

Someone accountable for revenue on the travel line. Pilots that belong to no one's P&L produce a demo and nothing after it.
Enough volume to be worth automating

Enquiries arriving faster than a team can answer them one by one. That is where this starts showing up in the numbers.

The offer

Three pilot partners. Not a waiting list.

The banking, OTA and loyalty modules are built and running. A pilot configures what already exists against your brand and your suppliers. Three at a time is what gets our full attention.

What a pilot is

One surface and one supplier set, fully branded as you
Live and taking real bookings, not a demo environment
Your rates, your rules, your customer
Scoped and agreed before anything longer is signed

Why this year

Retail settled cart and checkout two decades ago. Travel still sells one vertical at a time
One cart, one total, one confirmation, one cancellation that needs no phone call
That plumbing takes years to build. It is running now
The teams buying an LLM chatbot this year are buying something that cannot take a payment

Every trip your customers book today is bought in pieces, because nothing you can hand them holds the whole thing in one cart.

Take one of the three

How a project runs

What you bring, what we do.

You bring

A surface: your engineers, a storefront to brand, or a channel
Your supplier credentials and negotiated rates, where you have them
Brand: name, colours, tone, domain
Your pricing rules and commercial terms

We do

Issue API credentials, brand the storefront, or connect the channels — whichever you came for
Wire in your providers and merge them into one result list, or run you on ours
Wire up payment — Stripe in your account, your own gateway, or your existing rails
Run it, monitor it, and handle post-sale automation

API credentials: same day. A branded storefront or a live channel is scoped work, and we put a date on it in the first conversation.

Architecture

Where the model is, and where it isn't.

A monolithic service in Rust handling availability, pricing, cart state, booking and post-sale. Deterministic: same input, same itinerary, same price, every time.

A normalisation layer maps every supplier schema into one internal representation, so adding a supplier never changes booking logic.

Language models do one job: talking to the end user. They never select inventory, compute a price or commit a booking. Remove them and the engine still runs.

Rust core

Deterministic booking path

Provider-agnostic normalisation

Per-partner provider config

No token cost per booking

Architecture diagram. A conversation layer running a language model sits to one side of the booking path, not within it: it interprets intent and phrases replies, and holds no booking authority. It passes a structured request sideways into the deterministic core, written in Rust, which owns availability, pricing, cart state, booking, cancellation and refunds, and contains no model inference. The core connects to a payment layer running on Stripe or the partner's own gateway, holding no card data. Below the core, a provider-agnostic normalisation layer maps every supplier into one internal schema, and beneath that sit the supplier APIs — more than fifteen integrated, across GDS, NDC and bedbanks. Partners connect their own credentials, or use ours.

What you get

What the platform actually does

Capabilities, not superlatives. Each one is something you can put in front of a customer.

Deterministic booking path

Same input, same itinerary, same price. No model inference decides what gets booked, so a bad model day cannot become a bad booking.

Reproducible

One cart, every supplier

The customer builds an itinerary across messages and reviews it as one summary. Checkout books every supplier in it as one run, stopping at the first item that baulks rather than charging on in silence.

Multi-item cart

Payment on your rails

Cards in your own checkout, a provider's hosted page, or Stripe. Each provider is charged as its own item books, and the card is never stored. Your own gateway or internal rails connect instead. Merchant of record is set per partner.

Payments your way

Cross-sell in the same thread

Ancillaries offered in the conversation that produced the booking. No redirect, no second checkout.

Ancillary revenue

Closed user group distribution

Closed user group and private rate channels are supported. The supplier decides what goes to a closed channel; we carry that decision.

CUG / private rates

Automated post-sale, or we don't ship it

A provider goes live only when cancellation and refund work without a call centre. Your customer changes or cancels where they booked — no phone number, no ticket for your support team.

Full lifecycle

Full white label

Your domain, brand, tone, pricing rules and reporting. GoChatTravel is not named anywhere the customer can see. You own the relationship and the margin.

Invisible engine

Six live channels, plus your own app

WhatsApp, Telegram, Slack, Teams, Messenger and Instagram Direct are live. Slack and Teams reach a different buyer — corporate travel is already discussed there. Other messengers and your own app on request.

Multi-channel

Travel policy, applied before the booking

Caps, cabin and room class, advance purchase, preferred suppliers — applied while the traveller is still shopping. Out-of-policy is labelled there, not found by finance a month later.

Policy engine

Approvals where the work already happens

Sign-off goes to the approver in the Slack or Teams channel the company already lives in. One tap, and the held cart checks out. This runs in front of whatever programme you already have, and it is the step those tools lose people on.

Approval flow

A checkout run with nothing booked yet. The flight from Montreal to Paris is marked Under review, with the line: a payment was sent for this item and we are still confirming it with the provider. The hotel below it is still waiting. A control offers to stop after the current item. — **Money left, the provider has not answered yet.** Every risk team asks what happens here. It is a state the traveller can see, not a spinner — and nothing retries a charge behind their back.

Where we sit

We are the layer, not the supply.

We do not sell you inventory and we are not trying to out-supply the people who do. We connect to them — Duffel, Nuitée, the GDSs, bedbanks, your own direct agreements — and put one cart, one checkout and one post-sale flow on top, in whatever interface you sell through.

You only need hotel supply

Go to a hotel specialist directly. More properties, cheaper, and you will not be paying for a layer you are not using.
You only need flights

Same answer: go direct to a flight API. One vertical, one supplier, no cart to speak of — you do not need us for that.
You already have a corporate travel programme

Good — keep it for duty of care, expense and mid-office. We go in front of it: the basket, the checkout, and the approval where your people already talk.
You want a cart and a checkout over what you already have

That is us. Several suppliers in one basket, settled together, with policy and approvals running where your people already talk — on top of the programme or the supplier you already pay for.

We do not charge for search, because we are not the one selling you the inventory. If a supplier you brought charges for its own searches, that stays between you and them.

Comparison

How this compares

Not against the suppliers themselves — we sit on top of those. Against the two things you would otherwise do: build this layer yourself on their APIs, or hand the job to an LLM-agent tool.

Capability comparison between GoChatTravel, building directly on supplier APIs, and LLM-agent travel tools.
Capability	GoChatTravel	Direct on supplier APIs	LLM agent tools
Deterministic booking path	Yes	Yes	No
Runs inside chat with no front end to build	Yes	No	Yes
Persistent multi-item cart across messages	Yes	You build it	No
Checkout included, or your own rails	Yes	You build it	No
Travel policy and approval flow	Per partner	You build it	No
Automated cancellation, or the provider is not shipped	Yes, or we drop the supplier	Provider-dependent	Rarely
Closed user group / private rate channel	Yes	Provider-dependent	No
Bring your own GDS / NDC credentials	Yes	Sometimes	No
Engineering effort required from you	None, or as much as you want	Substantial	Moderate
Per-booking token cost	None	None	Yes

Bring your own

Almost none of this has to be ours.

The engine is a core with adapters around it. Every one of these slots takes what you already have, or ours if you would rather not hold it.

Your suppliers

Your credentials, your negotiated rates, and those are the rates your customers see. One we have not met before is an adapter, not a project — connecting it never touches booking logic.

Amadeus, Sabre, Travelport GDS
Direct NDC agreements at your fares
Bedbanks, wholesalers, direct chain APIs
One we have not connected yet: weeks, not a quarter
Or run on ours, where you hold none

Your interface

Chat is one way to shop, a web form is another. Both sit on the same engine, so the surface is a choice rather than the product.

Call the API from your own web or mobile app
Brand the reference storefront and ship it
Embed the assistant, or leave it out
Or take a chat channel, turnkey

Your channels

The numbers and workspaces your customers already message. We configure them; you keep them.

Your WhatsApp Business number
Your Telegram bot token
Your Slack or Microsoft Teams workspace
Your Messenger and Instagram pages

Your payment rails

Each provider is charged as its own item books, and the card is never stored. Whose rails carry that is yours to decide.

Your PSP, gateway or internal rails
A provider’s own hosted payment page
Or Stripe, with nothing to set up
Merchant of record set per partner

Your customer’s identity

You issue the token, we verify it. We never become the identity provider for someone else’s customer.

A delegated JWT you already issue
SSO, or your own IdP
Server-to-server API keys
No second account for your customer to hold

For Partners

Who this fits today

Four shapes of partner the engine already fits, and what each one plugs in.

Regional OTAs & tour operators

Add a chat channel and inventory breadth without hiring an engineering team to build distribution.

Sell in chat alongside your existing site
Your supplier contracts, or ours
Cross-sell inside one conversation
Your brand, your margins

Loyalty programmes & fintechs

Turn points, cashback or a card programme into a travel product without owning travel technology.

Booking inside your app or chat channel
Payment flow adapted to your rails
Points and rewards applied at checkout
Closed user group rates for members

TMCs & corporate travel

We are not the travel programme. We are where the trip gets bought — in front of whatever you already run, in the channel your people already use.

Travel policy applied at search and at checkout
Approvals in Slack or Teams, not by email
Hotels, flights, car rental and events in one cart
Your negotiated corporate rates

Airlines & larger enterprises

Add hotels, car rental and events to your existing channels, on your own NDC and GDS connections.

Ancillary attach in chat channels
NDC and GDS connections supported
Private fare distribution via CUG
Closed-channel member pricing

Commercial terms are set per partner.

A loyalty programme with its own hotel contracts and an OTA on our suppliers are not the same deal. Tell us which you are and we put numbers on it in the first conversation.

Book 30 minutes info@gochattravel.com

One engine. Any interface. Any provider.

This is a real cart, not a mockup.

One engine. You choose how much of it you touch.

The API

Reference storefront

Chat channels

You are not buying inventory. You are buying a shop to sell it in.

A channel you cannot currently sell in

One cart, the whole trip

Your contracts, your prices, your margin

As much engineering as you want, including none

You have already paid to acquire this customer.

This lands hardest when four things are already true.

Customers already message you

You have inventory, or a reason to sell ours

Someone owns the number

Enough volume to be worth automating

Three pilot partners. Not a waiting list.

What a pilot is

Why this year

What you bring, what we do.

You bring

We do

Where the model is, and where it isn't.

What the platform actually does

Deterministic booking path

One cart, every supplier

Payment on your rails

Cross-sell in the same thread

Closed user group distribution

Automated post-sale, or we don't ship it

Full white label

Six live channels, plus your own app

Travel policy, applied before the booking

Approvals where the work already happens

We are the layer, not the supply.

You only need hotel supply

You only need flights

You already have a corporate travel programme

You want a cart and a checkout over what you already have

How this compares

Almost none of this has to be ours.

Your suppliers

Your interface

Your channels

Your payment rails

Your customer’s identity

Who this fits today

Regional OTAs & tour operators

Loyalty programmes & fintechs

TMCs & corporate travel

Airlines & larger enterprises

Commercial terms are set per partner.