Ask Each Supplier in Batches It Accepts
Hand over a few more cards than the other side will take, and it may take none at all.
One supplier’s hotel search accepts at most 1,500 hotel IDs per request. Lists above that limit are now asked in batches of 1,500, one after another, and the results merged in the original order; if any batch fails, the search reports the error instead of passing off part of the answer as complete.
Buyers’ hotel lists keep growing, and a thousand or more hotels in one city or destination is no longer unusual. During a search the system hands those hotel IDs to each supplier to price. Every supplier has its own limit on how many hotels one request may ask about, and the number is often tucked away in a corner of the API documentation.
One supplier’s hotel search takes at most 1,500 hotel IDs per request. Send a list just a few dozen over and it does not price the first 1,500; it rejects the whole request as invalid input, in a reply that looks successful but contains an error. The search with that supplier then fails as a whole, and not a single hotel price comes back from it.
Lists above the limit are now split into batches of 1,500 inside this supplier’s search, asked one batch after another, and all results are merged back in the original order. The hotel list the caller handed over stays exactly as it was. We considered two easier routes: cutting the list at 1,500 would silently drop the hotels after it, and a longer timeout would not lift the supplier’s limit. Splitting was the only route left.
Splitting brings a choice of its own: if any batch fails, the search returns the error instead of handing over the successful batches as the full result, because missing hotels should not be quietly hidden. Searching by city is unaffected and no new setting was added; the limit lives in this supplier’s own integration, next to the rest of its rules.