Blocking Search API

The Blocking Search API waits for all configured suppliers to respond before returning a result. Unlike the Asynchronous API where results stream in batches, Blocking returns the complete result set in a single response — along with the search token.

POST{baseEndpoint}/api/hotel/availability

Identical request structure. The Blocking and Asynchronous Search APIs accept exactly the same request body. You can switch between them without changing your search criteria logic.

Blocking vs Asynchronous — when to use each

This page — Blocking

Use when

Building internal tools or B2B flows where wait time is acceptable
Prototyping or testing — simpler to implement
The result set is small (few suppliers, limited inventory)
You want token and results in one call

Asynchronous Search API

Use when

Building a B2C or customer-facing product
You have multiple suppliers with varying response times
User experience matters — results should appear progressively
Search covers high-inventory cities (hundreds of hotels)

What the response includes

Because blocking waits for all suppliers, the response contains both the search token and the complete hotel list in one payload. From here the flow is identical to Asynchronous — use the token for Rooms & Rates, Pricing, and Booking.

Polling still possible after blocking. The blocking response does return a token, and you can still call the async poll endpoint with that token to check if any late-arriving suppliers have added results. This is uncommon but supported.