Booking.com Connectivity vs Expedia Rapid vs Hotelbeds

These products do not solve the same technical problem. Booking.com Connectivity is a distribution/connectivity contract, while Expedia Rapid and Hotelbeds are B2B lodging shopping/booking supply platforms. The useful comparison is therefore lifecycle and ownership, not a generic API ranking.

Comparison matrix

Architecture difference

For Booking.com Connectivity, the source of truth is usually the PMS/CRS/channel manager. The system projects ARI/content state to Booking.com and consumes reservation state in return.

Rapid and Hotelbeds are buyer-side supplier APIs: search external supply, normalize offers, revalidate where required, create bookings and service them.

Connectivity:
PMS/CRS -> ARI/content -> Booking.com
Booking.com -> reservation -> PMS/CRS

Supply API:
Buyer search -> supplier offer -> reprice/check -> booking -> servicing

Ownership and canonical model

Booking.com emphasizes room/rate mapping, sellability, reservation delivery and acknowledgement.

Rapid/Hotelbeds emphasize canonical hotel/room/offer, supplier references, price components, cancellation terms, booking references and payment ownership.

Treating all three as one generic "hotel API adapter" creates a lifecycle abstraction error.

Reprice difference

Rapid uses Price Check as the selected-rate transaction boundary. Hotelbeds requires CheckRates when rateType=RECHECK; BOOKABLE can proceed directly to booking.

Booking.com Connectivity does not expose a generic metasearch search → reprice → book lifecycle; it manages distribution state and inbound reservations.

Failure modes

Booking.com Connectivity

• stale ARI,
• mapping drift,
• reservation queue lag,
• persist/ack ordering errors.

Expedia Rapid

• expired booking link,
• price changed,
• sold out,
• unknown booking outcome.

Hotelbeds

• stale rateKey,
• skipped CheckRates,
• signature/mTLS failure,
• duplicate booking after timeout.

When to use which

If you distribute property inventory to Booking.com, use Connectivity.

If you build hotel search/OTA/metasearch and need external bookable supply, Rapid or Hotelbeds are the relevant product families.

In multi-supplier architectures, Rapid and Hotelbeds can normalize into one canonical Offer contract while keeping provider-specific revalidation and booking semantics inside adapters.

Decision checklist

• Am I the supplier or the buyer?
• Who owns inventory source of truth?
• Who creates the booking?
• Is reprice/validation required?
• Am I consuming reservations or creating supplier bookings?
• Who owns payment/merchant responsibility?
• Where do mapping and reconciliation live?