Connecting Booking.com and Expedia to Sabee.

How the connection actually works

Both Booking.com and Expedia expose a machine-to-machine interface that a channel manager like Sabee uses to push rates, availability and restrictions out, and pull reservations back in. Booking.com's is an XML-based interface tied to your Hotel ID (or a Group ID if several properties sit under one chain account); Expedia's runs through what's commonly called EQC — Expedia QuickConnect — authenticated with credentials issued from Expedia Partner Central. Neither connection requires you to touch XML directly when you're connecting through Sabee; the underlying protocol matters mainly for understanding what can and can't be controlled remotely, and for reading error messages that occasionally surface the raw channel response.

Sabee maintains the connection in both directions continuously once it's live: a rate change you make in Sabee's calendar pushes out to both channels within minutes, and a reservation made on either channel pulls back into your Sabee tape chart and closes that inventory everywhere else automatically. This is what "two-way sync" means in practice, and it's the entire point of running a channel manager rather than logging into each extranet separately.

What you need before you start: Booking.com

To connect Booking.com, you need your property's Hotel ID (found in the Booking.com extranet under your property details, or provided by your Booking.com market manager) and, for a chain or group account, the Group ID that sits above individual property IDs. Booking.com also requires an explicit connectivity request approved on their side — your Sabee consultant submits this on your behalf, but Booking.com's own approval can take anywhere from same-day to a few business days depending on your market.

You'll also want your existing Booking.com room and rate plan names on hand, because the next step is mapping — matching what exists on Booking.com's side to what you've built in Sabee.

What you need before you start: Expedia

Expedia's connection runs through Expedia Partner Central (EPC). You'll need your EPC login credentials, or — more commonly for an existing Expedia partner — you'll grant Sabee's connectivity partner access directly inside EPC's "Connectivity" settings, which avoids sharing your actual login. If your property is new to Expedia, onboarding there runs on a separate timeline from Sabee's own onboarding, since Expedia has its own account approval and contracting process independent of any channel manager.

Expedia also distinguishes between rate plans that are "Member-only" style discounted rates and standard public rates, and its restriction model (covered below) differs from Booking.com's in a few important ways that catch people out.

Rate and room mapping

Mapping is the process of telling Sabee which of your internal room types and rate plans correspond to which listing on each channel. This matters because a channel manager doesn't "know" that your Sabee "Deluxe Double" is the same product as Booking.com's "Deluxe Room, 1 Double Bed" — you tell it once, and every subsequent rate and availability push uses that mapping automatically.

Practical mapping steps:

• Match room types one-to-one where possible. If Booking.com lists four room categories and you've built four room types in Sabee, map them directly. Where the counts don't match — say Booking.com has a combined listing that Sabee splits into two room types — you'll need to either consolidate in Sabee or split the listing on the OTA side before mapping.
• Map each rate plan individually. A flexible rate and a non-refundable rate for the same room type are two separate mappings, even though they share a room type.
• Set derivation correctly. If your non-refundable rate is meant to always be 10% below flexible, decide whether that derivation lives in Sabee (recommended, since it's one source of truth) or is set independently on each channel — the latter creates parity risk the moment you change one without the other.
• Confirm currency. Most properties sell in EUR across all channels, but if a channel is configured in a different currency, mapping needs to account for the conversion rather than assuming a 1:1 rate match.

Restrictions per channel

Restrictions are the rules layered on top of price and availability: minimum length of stay, maximum length of stay, closed-to-arrival (CTA), closed-to-departure (CTD), and stop-sell. Both Booking.com and Expedia support all of these, but they don't always behave identically, which is the source of a lot of confusion.

Booking.com applies restrictions at the rate-plan level and generally respects granular day-by-day changes pushed from a channel manager reliably. Expedia's restriction handling can lag slightly on propagation — a restriction change pushed from Sabee may take a short while longer to reflect on Expedia's live site than the same change on Booking.com, which is normal and not a sign of a broken connection, though it's worth knowing so you don't panic-refresh Expedia's site five minutes after a change.

A minimum-length-of-stay (LOS) rule set incorrectly is the single most common cause of "why did we get a one-night booking over our busiest weekend" complaints. Set LOS rules at the rate-plan level in Sabee for the specific date ranges that need protecting — a peak-weekend two-night minimum, for instance — and confirm on a test push that the restriction actually reached both channels rather than assuming it did because it saved correctly in Sabee.

Length-of-stay controls in more detail

Beyond a flat minimum stay, Sabee supports arrival-day-specific LOS rules (a two-night minimum only for Friday and Saturday arrivals, for example) and length-of-stay-based pricing, where a seven-night stay gets automatically discounted relative to a one-night rate. Both of these need to be tested per channel, since not every OTA interprets a "minimum stay on arrival day X" rule the same way — Booking.com generally supports arrival-based LOS cleanly; confirm Expedia's handling with a test push rather than assuming parity between the two.

Sending a test push

Before switching a channel to live two-way sync, send a test push: a rate and availability update for a short date range in the near future, ideally a week with low real demand so a mistake doesn't cost you a real booking. Confirm three things land correctly on the OTA extranet side: the price shown matches what you set in Sabee, the room type name and description match your mapping, and any restriction (minimum stay, closed dates) is visible and correctly dated.

Only after a test push is confirmed clean should stop-sell be lifted and the channel switched to accept live bookings. This single step — testing before going live rather than assuming the mapping is correct — is what separates a clean channel connection from a week of manual rate corrections.

Common errors and how to read them

"Rate plan not found" or mapping rejected

Usually means the rate plan referenced on the OTA side was renamed, deleted, or never existed under the ID Sabee is pushing to. Re-check the mapping against the current state of the OTA extranet — rate plans do get renamed or restructured by hotels directly on the channel side occasionally, which breaks a previously-working mapping.

Availability shows correctly but rate doesn't update

Often a derivation conflict — a rate plan set to derive from a parent rate inside Sabee, but also configured with an independent rate override still active on the OTA side from before the Sabee connection existed. Clear any legacy override on the channel side and let Sabee's push be the single source.

Reservation pulled into Sabee with the wrong room type

Almost always a mapping mismatch created during initial setup — the OTA listing was matched to the wrong Sabee room type. This needs a mapping correction, not a manual fix per reservation, or it will keep recurring.

Restriction pushed from Sabee doesn't appear on Expedia

Check propagation timing first (see above) — wait 30 to 60 minutes and recheck. If it still hasn't appeared, confirm the restriction type is one Expedia's EQC interface supports for that specific rate plan category, since Member-only rate plans occasionally have different restriction support than standard public rates.

Channel shows "connection error" intermittently

This is typically transient on the OTA side rather than a Sabee-side fault — both Booking.com's XML interface and Expedia's EQC occasionally have short outages or maintenance windows. Sabee automatically retries failed pushes; a single connection error that resolves on the next automatic retry doesn't need manual intervention. Persistent errors over several hours are worth flagging to support.

After both channels are live

Once Booking.com and Expedia are both on two-way sync, the discipline that matters most is making every rate and restriction change inside Sabee rather than logging into either extranet directly. Manual changes made on an OTA extranet don't sync backward into Sabee automatically in the same way, which creates exactly the parity mismatch described in our rate parity guide. Sabee becomes your single source of truth precisely because every channel is reading from it — that only holds if nothing overrides it from the other direction.

If you're adding more than these two channels, the same mapping-then-test-push discipline applies to each one, though most secondary OTAs follow simpler restriction models than Booking.com or Expedia and connect faster as a result.

Booking.com and Expedia specifics worth knowing in advance

A few channel-specific behaviours are worth understanding before your first connection rather than discovering mid-setup. Booking.com's Genius programme and its various promotional plans (Mobile rate, Country rate, and similar targeted discounts) are configured on Booking.com's own extranet rather than through your channel manager — they layer on top of your base mapped rate rather than replacing it, so a Genius discount you opt into on Booking.com's side won't appear as a separate rate plan inside Sabee, but will show as a lower effective price to eligible guests on Booking.com itself. Decide deliberately whether you want to participate in these programmes rather than having them enabled by default, since they affect your effective ADR on that channel without changing what Sabee reports as your base rate.

Expedia, similarly, runs its own promotional tools (Expedia's TravelAds and various member-discount programmes) independently of the base rate and restriction mapping described above. These sit alongside your channel manager connection rather than inside it, and are worth reviewing separately with your Expedia account manager once the core connection is stable.

Sold-out and stop-sell handling

When a room type sells out on one channel, Sabee's two-way sync closes that inventory across every connected channel automatically, rather than requiring a manual stop-sell on each OTA individually. This is one of the clearest demonstrations that the connection is working correctly during your first week live — book out a room type through one channel (or manually mark it full in Sabee) and confirm it disappears from availability on both Booking.com and Expedia within the expected sync window, rather than staying bookable on a channel Sabee hasn't yet updated.

Handling overbookings during the transition period

In the days immediately after switching a channel to live two-way sync, keep a manual eye on your tape chart for the first week rather than assuming the connection is fully self-sufficient from hour one. An overbooking during this window is almost always traceable to a mapping gap rather than a fundamental fault in the sync itself — a room type that existed on the OTA side but wasn't included in the initial mapping, for instance. Catching this in the first week, while you're already reviewing the connection closely, is considerably easier than discovering it during a busy period a month later.