One shape for every source
Fares from the Amadeus GDS and from airline-direct NDC come back in the same structure. You integrate once against the travel API, and adding a source later doesn't mean rewriting your client.
Travel API · GDS and NDC
One travel API. Both rails.
Search, book, and issue through a single flight booking API — with the Amadeus GDS and airline-direct NDC behind it, normalised into one shape. Build against the sandbox, go live when you're ready.
One integrationboth rails
shop/offers
price · book/orders
issue · reissue/tickets
refund · void/tickets
Response shape1
Same structure, whichever source answered
00What you get
The engine, not a wrapper around it.
The lifecycle, not just the search
Shop, price, book, issue, reissue, refund, and void — the same operations the platform runs on, exposed as an API rather than reimplemented behind one.
A GDS API and an NDC API in one
Rather than integrating a GDS API and an airline's NDC API separately and reconciling the difference yourself, both arrive through the same endpoints in the same shape.
A sandbox first
Build and test against a sandbox before anything touches production or a real ticket.
Built to be built on
The same engine that runs the platform. If you're selling infrastructure to your own partners rather than a portal to your own staff, this is the layer to build on.
01Questions
Before you start building.
What can the API do?
Search, price, book, issue, reissue, refund, and void — across the Amadeus GDS and airline-direct NDC.
Is there a sandbox?
Yes. Build and test against it before touching production.
Do we need our own Amadeus or NDC agreements?
Your own airline NDC agreements can be plugged in. Talk to us about how your supply is set up today.