Booking and Expedia Integration Step by Step: Installation and Testing Process

The goal of this guide is not to “count panel steps”; It is about establishing a discipline that will catch errors before they go live. Quality of integration; Mapping accuracy is measured by the test booking matrix and the first 30 days monitoring cadence.

Before setup begins, your “definitions” should be clear in Booking and the Expedia extranet. Because mapping is linked to definition; If the definition is blurry, the mapping will also be blurry. If you make this preparation correctly, decisions will be accelerated on the PMS and channel manager side.

• •Room types: In the resort scenario, the main room + variations (view, capacity, concept) should be defined simply.
• •Price plans: Plans such as refundable / non-refundable / early booking / last minute should be placed on the naming standard.
• •Policies: cancellation, prepayment, minimum stay and package contents should be clarified.
• •Market/market combinations: e.g. If certain markets in Antalya/Belek have different minimum night rules, it should be written down.

There are two critical decisions at this stage: (1) What is the only source of truth? (Is the price/restriction in PMS or channel manager?) (2) Who manages which panel? (RM, reservations, front desk, agency/IT). General practice: PMS becomes the reality of the operation, the channel manager is the distribution and rules engine. The important thing is not to write rules in two places.

Minimum set for connection installation

• •PMS ↔ Channel manager API/connector activation
• •Channel list: Booking + Expedia (and others if available)
• •Update frequency/latency expectation (in minute level)

How to integrate Booking and Expedia? (5–7 steps)

• •Match room types (RoomType): Link room types in PMS/CM to their room counterparts in OTA.
• •Match rate plans: Link BAR, refundable, non-refundable, promotional plans to OTA rates.
• •Define the restriction set: Determine how restrictions such as min stay, stop-sell, CTA/CTD will be distributed to which channels.
• •Verify tax/commission logic: net/gross price approach and check included/excluded items.
• •Lock inventory update rule: make clear salable room logic, allotment and closing procedure.
• •Perform a “mapping audit” with sample combinations: create a quick verification table for each room type × each rate plan.
• •Move to the test booking stage: run all critical scenarios before going live.

Relational expression: RoomType → mappedTo → OTA Room, RatePlan → mappedTo → OTA Rate; TestReservation → validates → mapping + restriction + cancellation flow.

Most competing content stays superficial here: it says “test” but doesn't tell you what to test. The part that makes the difference should be your test booking matrix and error scenario procedure.

Minimum test set (per hotel)

• •Test-1: Room type A + Rate plan BAR → reservation → PMS drop control
• •Test-2: Room type A + Non-refundable → payment/prepayment logic check
• •Test-3: Min stay rule → Does it behave correctly in OTA?
• •Test-4: Stop-sell → does the sale close, how long does it take to close?
• •Test-5: Cancellation → Is OTA cancellation reflected correctly in PMS?
• •Test-6: Is the date change / modification → rate difference and availability update correct?

Error scenarios (resort facts)

• •Wrong price appears → RatePlan mapping/taxes/rounding
• •The sale does not close → stop-sell distribution is delayed or written from the wrong panel
• •Overbooking risk → inventory update/two panel conflict
• •Cancellation flow broken → connector setting/reservation status mapping

Going live is not a technical “switch”; is the stabilization process. Especially in the first 7–14 days, small errors can quickly escalate. Therefore, monitoring rhythm and sharing of responsibility are essential for the first 30 days.

First 30 days monitoring KPI set (practical)

• •Number of overbooking incidents (weekly)
• •Price consistency check (spot-check)
• •Update latency observation
• •Cancellation/modification flow accuracy
• •Channel-based net ADR (post-commission perspective)

Data point in case language (smoothed): With correct room & rate mapping, overbooking and price inaccuracies are significantly reduced; In hotels where the testing process is skipped, there is usually a need for more intensive support and correction in the first week.

Success in Booking and Expedia integration does not depend on a single settings screen. When the standard definition of room and rate plans, room/rate mapping accuracy, test reservation discipline and first 30-day monitoring rhythm work together; The risk of incorrect prices, closing errors and overbooking is significantly reduced.