Travel API evaluation checklist: what to ask before you integrate

Start with your own scope, not the provider’s feature list

Not sure an API is what you need? If your team doesn’t plan to build its own front end, read B2B travel portal vs booking engine vs travel API first.

Before you compare providers, write down the following.

• Verticals you’ll sell in the next 12–18 months: flights only, or flights plus hotels, insurance, ground?
• Content sources that matter for your market: GDS, airline NDC, low-cost carriers, bedbanks, your own contracts.
• What stays in-house: your UI, pricing and markup logic, customer data, payments.
• Who maintains integrations after go-live, and how many engineers you can spend on supply plumbing.

A provider that fits a flights-only OTA can be the wrong choice for a team planning a multi-vertical basket next year. Scope first; it turns a demo into a test.

Schema: is it really one model, or many APIs behind one URL?

“Unified” can mean very different things. Ask these questions.

• Do flights, hotels and other verticals share the same core objects (offer, order, traveller, payment), or does each vertical have its own shapes?
• When the source is GDS vs NDC vs LCC, does the response look the same, or do you still branch on the source in your code?
• Is there a published, versioned schema (for example an OpenAPI definition) you can generate clients from?
• How are breaking changes handled: version bumps, deprecation windows, changelog?

If you’ll still write supplier-specific code on your side, you’re buying a proxy, not a unified API. For the model behind this, see What is a unified travel API?

For a vertical-level example, see how one schema covers GDS, NDC and LCC in our flight booking API.

Search vs price at booking: how honest is the cache?

Fast search usually depends on caching. The question isn’t whether a provider caches; it’s what happens when the cached price is wrong.

• How are cached prices refreshed, and how is the fare re-verified before booking?
• What does your app receive when the price changes between search and book: a clear error, a new offer, or a silent failure?
• How does the provider avoid sending every search to every supplier (and the look-to-book cost that follows)?

Ask for the price-change and availability-change flows in the sandbox, not just the happy path.

Orders and servicing: what happens after “booked”?

Most integration cost lives after the booking. Ask these questions.

• Is there one order model for create, change, cancel and refund across verticals?
• Which post-booking actions are API-driven and which still need an email or a support ticket?
• Are webhooks available for order, ticketing, payment and similar events, and can they be replayed if your endpoint was down?
• Are requests idempotent (safe to retry with the same key) so a timeout doesn’t create a duplicate booking?

Retries deserve their own test. In the glossary: idempotency.

Supplier changes: who notices, and who fixes?

Suppliers change their APIs, often without notice. This is the single biggest long-term cost of owning integrations.

• When a supplier changes a field or enum, how is it detected, and how fast is a fix promoted?
• Are mapping changes versioned, logged and reversible?
• Will your team be told what changed, or find out from failed bookings?

We cover how this can be automated in Self-healing supplier connectivity. In the glossary: schema drift and schema versioning.

Content coverage: NDC, LCC and your own contracts

Ask which airlines and content types are live today for your markets, and which are “on the roadmap”. Ask for the list in writing.

Check whether NDC content is returned in the same shape as GDS content, including fare families and ancillaries. See NDC beside GDS and LCC.

Ask whether you can load your own negotiated fares or hotel contracts into the same feed, or whether they need a separate system. See Private fares next to GDS content.

Sandbox and developer experience

A sandbox tells you more than a slide deck.

• Does the sandbox use the same mappings and behaviour as production, or a simplified mock?
• Are API keys, per-key rate limits and request logs available to your team?
• Are there Postman collections or typed clients, and is the documentation complete enough to build without a call?
• Can you test errors: timeouts, sold-out, price change, partial failure in a multi-item basket?

Operations, hosting and data

• Where is the platform hosted, and can you choose a region if you have data-residency needs?
• What do the SLA and support terms say in the contract (not the website), and how are incidents communicated?
• Can you see health per supplier so you know whether a failure is yours, the provider’s or the airline’s?
• Who owns customer and booking data, and can you export it?

Commercials and lock-in

• How is the API priced: per booking, per search, flat platform fee? Are look-to-book limits passed on to you?
• What does it cost to add a vertical or supplier later?
• If you leave, what do you take with you: order history, traveller data, your own contracts?
• Does the provider sell to travellers or agencies in your market itself? A partner that competes with you has different incentives.

A simple scoring sheet

Score each provider 1–3 on each area, weighted by your scope. The weights below are an example; set your own before the first demo so the scoring isn’t shaped by whichever provider presents best.

• Schema (high): a 3 means one model across verticals and sources, with a versioned OpenAPI definition.
• Price accuracy (high): a clear re-price flow, tested in the sandbox.
• Orders and servicing (high): change, cancel and refund via API, with webhooks and idempotency.
• Supplier changes (high): detected, versioned, reversible and communicated.
• Coverage (medium): a written list for your markets, with NDC in the same shape.
• Sandbox and developer experience (medium): a production-like sandbox, logs and typed clients.
• Ops and hosting (medium): region choice, a contractual SLA and supplier health.
• Commercials (medium): transparent pricing, a clean exit and no channel conflict.

Where Elkanio Synapse fits

Elkanio Synapse is a unified travel REST API for OTAs and travel tech teams: one schema across nine verticals (flights from GDS, NDC and LCC, plus hotels, activities, insurance, visa, cab, bus, ferry and cruise), one order model with webhooks, and a sandbox that uses the same mappings as production. Supplier changes are handled by an agentic runtime that proposes a mapping patch, replays it against recorded traffic and promotes it behind a versioned mapping with rollback, with every change visible to engineers. Hosting options cover India, Singapore, the EU and Dubai. Elkanio powers its customers and does not launch a competing OTA against them.

If you’re building on travel supply, bring this checklist to a 30-minute demo and we’ll walk through it on the verticals you sell. Teams building their own product can also start from Synapse for tech teams and OTAs.