Supplier API rate limits: outbound throttling and quota management in travel platforms

Outbound rate limiting is the discipline of sending requests to a supplier no faster than the supplier allows. Most writing on rate limits is about protecting your own API from clients, as in designing B2B partner APIs. Travel platforms face the opposite problem just as often: the GDS, NDC airline APIs, bedbanks and hotel suppliers they depend on all enforce limits, and the platform has to live inside them. Exceed a limit and searches start failing; exceed it persistently and a supplier may throttle the account or raise it commercially.

What suppliers actually limit

Supplier limits come in several shapes, often at once, and they are usually written in the contract or integration guide rather than discoverable from the API itself:

• Request rate — requests per second or per minute, sometimes per endpoint.
• Concurrency — the number of requests allowed in flight at the same time, regardless of rate.
• Daily or monthly quotas — a total number of searches or availability calls in a period.
• Ratio limits — searches per booking, the look-to-book ratio, monitored over time and sometimes charged for when exceeded.
• Session limits — on session-based APIs, a cap on open sessions per credential.

Record each supplier’s limits as configuration, next to its credentials, not as constants in adapter code. Limits change when contracts are renegotiated, and they differ between test and production environments.

Why per-instance limits fail

The first rate limiter most teams write lives inside the application process: a counter or a sleep between calls. It works on one server. With four application instances and a dozen queue workers, each enforcing the full limit, the real sending rate is many times the contracted one.

The limit has to be enforced where all outbound traffic for a supplier passes through one decision point. Two common designs:

• A shared limiter in Redis — a token bucket or sliding window keyed by supplier and credential, checked atomically before each call. The patterns in Redis beyond caching apply directly.
• An outbound gateway — a small internal service or proxy that all supplier calls go through, which owns rate, concurrency and quota enforcement for every supplier.

The gateway is more work up front but becomes the natural place for logging, credential management and the metrics described in observability for travel API integrations.

Rate and concurrency are different controls

A rate limit alone does not stop overload. If a supplier slows down, requests take longer, more of them are in flight at once, and a platform that is perfectly within its requests-per-second limit can still exceed the supplier’s concurrency limit — or exhaust its own connection pool and worker threads.

Enforce both:

• a token bucket for the average rate, sized to allow the short bursts the supplier tolerates,
• a semaphore or concurrency counter per supplier, released when the call completes or times out,
• timeouts on every call, shorter for searches than for bookings, so slow requests cannot hold concurrency slots indefinitely.

Prioritise transactional calls

Not every request to a supplier is equally important. A search can be served from cache, retried or simply dropped from the results. A price check before payment, a booking, a ticketing request or a cancellation cannot.

Give transactional calls their own capacity:

• reserve a share of the rate and concurrency for booking-path operations that searches cannot use,
• queue searches behind that reservation and shed them first under pressure,
• never retry searches indefinitely — a search answered after the customer has left is pure cost.

Without this separation, a traffic spike from a metasearch partner or a bot can consume the quota and leave a paying customer facing a booking failure.

Reduce demand before you throttle it

The cheapest request is the one never sent. Before tuning limiters, reduce how much outbound traffic the platform needs:

• cache search results with lifetimes suited to the product, and re-price before booking, as covered in flight search caching strategies,
• coalesce identical in-flight requests so ten customers searching the same route at the same moment produce one supplier call,
• route searches only to suppliers that serve the market instead of fanning out to every connection,
• filter automated traffic at the edge before it reaches the search pipeline.

These levers also improve the look-to-book ratio, which is often what the supplier is really watching.

Handling 429s and throttling responses

When a supplier signals that you are sending too much — usually HTTP 429, sometimes 503 or a supplier-specific error code inside a successful HTTP response — the platform’s reaction decides whether the problem stays small.

• Honour Retry-After when the supplier sends it, and pause that supplier’s traffic accordingly.
• Adapt the local limit. Lower the sending rate for that supplier after throttling responses and raise it gradually after a period of success, rather than relying on a fixed number that may be wrong.
• Retry only what is safe to repeat. Searches and reads can be retried; bookings and payments need idempotency keys or a status check first, because a throttled response does not always mean the supplier did nothing.
• Use exponential backoff with jitter so workers do not retry in synchronised waves.
• Open a circuit breaker when a supplier keeps failing, and return results from other suppliers instead of making every search wait for the slow one.

Map supplier-specific throttling errors into one internal error type in the adapter, so the gateway can apply the same policy to every supplier.

Fairness between tenants

On a multi-tenant or white-label platform, several customers often share one supplier credential. One agency running a bulk availability job can then starve every other agency.

Split the shared limit into per-tenant budgets — a guaranteed minimum for each tenant plus a shared pool for bursts — and make bulk or background work, such as cache warming or hotel content refreshes, run at the lowest priority. Where contracts allow, give large tenants their own supplier credentials so their limits are isolated.

Measuring it

You cannot manage a quota you cannot see. Track, per supplier and per credential:

• requests sent, by operation type,
• current rate and concurrency against the configured limit,
• throttling responses and how often local limiters delayed or rejected calls,
• quota consumed against the daily or monthly allowance, with alerts well before it runs out,
• searches per booking over time.

A dashboard that shows quota consumption trending toward the limit days in advance turns a supplier escalation into a routine capacity conversation.

Summary

Supplier rate limits are part of the integration contract, not an edge case. Store each supplier’s limits as configuration, enforce rate and concurrency at one shared point, reserve capacity for bookings over searches, reduce demand through caching and request coalescing, treat throttling responses as signals to slow down, and divide shared quotas fairly between tenants. Done well, the platform stays inside every supplier’s limits and the customer never notices that they exist.