Before a GDS or NDC integration: the questions that prevent surprises

Travel integration projects rarely fail early. They fail late, after the search works, when the booking path, the servicing path and the reconciliation turn out to be a different certification, a different rate limit, and occasionally a different commercial agreement.

The questions below are the ones worth answering before a scope is agreed. None of them are technically difficult. All of them are expensive to discover afterwards.

Does it cover the whole journey, or just search?

Search is the demonstrable part. Ask specifically which operations are supported end to end: search, price, book, ticket or confirm, amend, cancel, refund, and retrieve. Then ask which of those require separate certification and how long each takes.

A surprising number of integration plans are built on the assumption that if search works, the rest follows. It frequently does not, and the gap is usually discovered when the first amendment request arrives.

What are the real environments, and how do they differ?

Sandbox behaviour differs from production in ways that matter: data realism, latency, error rates, and whether the failure modes you need to handle can be triggered at all.

Ask directly how to simulate a timeout, a partial failure, a duplicate submission and a stale inventory response. If those cannot be produced in a test environment, the first time you see them will be in production with a customer attached.

What are the limits, and what happens when you hit them?

• Requests per second, per minute and per day — and whether those are per credential or per organisation.
• What the response is when a limit is exceeded: a clear error, silent throttling, or a temporary block.
• Whether limits differ between search and booking operations, which they usually do.
• How limits change with volume, and whether that requires a commercial conversation rather than a technical one.

Rate limits shape architecture. Discovering them after the caching strategy is built is an expensive reordering.

How are errors expressed, and can you act on them?

Error semantics decide how well a system degrades. Ask whether errors are structured or free text, whether the same condition always produces the same code, and — the important one — whether a failed booking request is reliably distinguishable from a request whose response was lost.

That last distinction is the difference between a safe retry and a duplicate booking. If the interface cannot make it, you need idempotency keys or a reconciliation process, and that is a design decision rather than an afterthought.

The question that saves the most money: can you tell a failed booking from a lost response?

Who owns the commercial dependencies?

Access, certification and content agreements are commercial, not technical, and they sit outside the engineering team's control. They are also the most common cause of integration timelines slipping.

Establish early who owns each dependency on your side, what the realistic lead time is, and what the project does while waiting. A plan that assumes certification completes on request is not a plan.

What does the data actually mean?

Two suppliers describing the same concept differently is the normal case, not an edge case. Fare rules, cancellation policy, passenger types, ancillary definitions and currency handling all vary in ways that leak into your product if nothing translates them.

This is the argument for a canonical internal model with supplier adapters at the boundary. Built early, adding a second supplier is an addition. Built late, it is a rewrite of everything that touched the first one.

How will you know it is broken?

Monitoring on integration flows is routinely deferred and routinely regretted. At minimum: success rate by operation, latency distribution rather than averages, error rate by type, and an alert when any of them moves.

The test of whether this is adequate is simple. If a supplier degrades at 3am, does someone find out from a monitor or from a customer? Most integrations are built for the second answer by default.

A short checklist

1. Which operations are supported end to end, and which need separate certification?
2. How do sandbox and production differ, and can failure modes be simulated?
3. What are the rate limits, per what, and what happens at the ceiling?
4. Are errors structured, consistent, and can a failure be told from a lost response?
5. Who owns access and certification on our side, and what is the real lead time?
6. What is the canonical model, and what translates into it?
7. What monitors the revenue-bearing flows, and who is alerted?

This is a general engineering guide. Appnox does not claim certification, partnership or affiliation with any distribution platform; connectivity is assessed per project against the access a client holds.