Observability for travel API integrations: logs, traces and supplier metrics

Observability for travel integrations means being able to answer, quickly and from data, what happened to any search or booking across every supplier it touched. A single customer search can fan out to a GDS, several NDC airline APIs and a set of hotel suppliers. When something fails, “the supplier is down” is rarely the full answer — and the support team needs the real one while the customer is still waiting.

The questions you need to answer

Design observability around the questions people actually ask:

• Why did this specific booking fail, and was the customer charged?
• Is a supplier slower or failing more than usual right now?
• Which suppliers return prices that change at booking?
• Did yesterday’s deployment change error rates for any integration?
• What exactly did we send and receive, for a dispute or an airline audit?

Each question maps to one of three tools: logs for specific events, metrics for trends, and traces for the path of a single request.

Correlation IDs everywhere

Generate an ID at the edge for every customer interaction and carry it through every internal service, queue message and supplier call. Keep a second, longer-lived ID for the order, so a search, a price check, a booking and a later cancellation can all be found together.

Where a supplier accepts a client reference, send your ID. Where it returns its own transaction or session identifier, record it next to yours. When you open a ticket with a supplier, their ID is the one their support team can search.

Log supplier traffic, safely

Request and response bodies are the most valuable debugging data a travel platform has, and the most sensitive. Log them, but:

• mask personal data and payment details before they are written — card numbers, security codes, document numbers, contact details,
• separate payload storage from general application logs, with stricter access and a defined retention period,
• record structured fields alongside the payload: supplier, operation, duration, HTTP status, supplier error code, correlation ID,
• sample search traffic if volume requires it, but keep every booking, ticketing, cancellation and refund call.

Masking has to happen in code before logging, not in the log viewer. Test it the same way as any other security control.

Metrics per supplier and operation

Aggregate metrics are almost useless in a multi-supplier platform: one failing supplier disappears inside a healthy average. Tag every metric with supplier and operation — search, price, book, ticket, cancel — and track:

• volume of requests,
• latency percentiles such as p50, p95 and p99, not just averages,
• error rate by type — timeouts, connection errors, supplier business errors, parsing failures,
• business outcomes — sold out at booking, price changed at booking, booking success rate.

The business metrics are the ones that explain revenue. A supplier that responds quickly but frequently fails at the booking step costs more than a slow one. These figures also feed commercial work such as look-to-book analysis.

Traces for fan-out

A search that calls many suppliers in parallel is a natural fit for distributed tracing. Each supplier call becomes a span with its own timing and status, and the trace shows at a glance which supplier held up the response or returned an error. OpenTelemetry provides a vendor-neutral standard for producing traces, metrics and logs, so the instrumentation does not tie the platform to one monitoring product.

Propagate the trace context through queues and background workers too. Ticketing, payment capture and confirmation emails often run asynchronously, and a trace that stops at the API boundary misses half the booking.

Alerts that mean something

Alert on symptoms customers feel, per supplier:

• booking success rate below its normal range,
• error or timeout rate above threshold for several minutes,
• latency percentiles well above baseline,
• background workers that stop processing — reconciliation, ticketing, time-limit housekeeping.

Define a normal range per supplier rather than one global threshold; integrations differ widely. Every alert should link to a dashboard filtered to that supplier and a runbook describing what to check and who to contact.

Connect observability to resilience

Good telemetry also drives automated behaviour. Per-supplier error rates can open a circuit breaker, temporarily removing a failing supplier from searches. Latency data sets sensible timeouts. Price-change rates inform caching decisions, discussed in flight search caching strategies. The supplier adapter layer described in GDS and NDC booking engine architecture is the right place to put this instrumentation once, for every integration.

Give support teams a booking timeline

The most useful observability feature for a travel business may not be a dashboard at all. It is a timeline view per order: every search, price check, booking attempt, payment event, supplier response and status change, in order, with masked payloads one click away. It turns a multi-hour investigation into a few minutes and is what makes disputes, refunds and airline debit memos manageable.

Summary

Carry correlation IDs through every service and supplier call, log supplier payloads with personal data masked and limited retention, measure every supplier and operation separately with percentiles and business outcomes, trace fan-out searches and async booking steps, and alert on what customers feel. Then turn the data into a per-order timeline so support teams can answer the question that matters: what happened to this booking?