Hotelbeds announced deprecation of their v2 REST API with a migration window that ends in early 2026. If your booking platform integrates with Hotelbeds, the move to v3 is not optional. But the migration order — what you change first, what you leave for later — determines whether you have a smooth cutover or a week of failed bookings.
The breaking changes that matter
V3 moves room distribution from a flat list to a nested rateKey + roomKey structure. If your booking flow assumes one rateKey per search result, you are in for a rewrite. Multi-room bookings now require room-by-room rate validation using the new checkRate endpoint. The old pattern of one availability call followed by one booking call no longer works for anything beyond a single-room booking.
Rate validation: the silent killer
The v3 checkRate endpoint returns a price that may differ from the search price by up to the supplier's tolerance. If you do not re-price before booking, you are accepting whatever the supplier charges at the confirmation step. TravelsOTA's implementation validates rates before every booking and rejects if the drift exceeds 5 percent.
mTLS is now a production requirement
While mTLS was optional in v2, Hotelbeds recommends it for v3 production traffic. Without it, your requests carry only API key authentication. With it, the connection itself is authenticated, reducing the blast radius of a key leak. TravelsOTA supports mTLS out of the box through its HTTP client configuration.
The migration order
Step one: update the content pipeline. Step two: migrate search. Validate results match v2. Step three: migrate rate check. Step four: migrate booking and cancellation. Never migrate two steps in one deployment.
