Expedia Rapid Lodging Integration Guide

An Expedia Rapid Lodging integration is not one “search hotel, display price, book room” API flow. A production design separates durable catalog data from short-lived shopping and booking state, validates the selected rate with Price Check close to transaction time, and manages booking attempts idempotently.

Expedia's documented lifecycle is effectively content → geography → shopping → price check → booking → retrieve/manage. Preserving the same boundaries internally prevents many stale-token, duplicate-booking and price-breakdown problems before they occur.

For product scope and transaction boundaries, see the Expedia Rapid profile. This guide focuses on implementation details.

Provider companion snapshot

Authentication contract

Rapid Lodging signature authentication:

api_key + shared_secret + unix_timestamp
            |
            v
SHA-512
            |
            v
Authorization: EAN APIKey=...,Signature=...,timestamp=...

The timestamp must match the value used to build the signature. Keep system clocks synchronized and never expose the shared secret to browser code.

Rate limits and performance-testing boundary

Rapid Shopping does not reduce to one universal QPS number. Expedia explicitly calls out request load dimensions including:

• number of properties,
• number of rooms,
• length of stay.

Measure rate-limit response headers where present and use the active partner configuration as the operational source of truth.

More importantly, Rapid setup documentation asks partners to review planned performance tests or major calling-behavior changes with the Rapid API consultant before running them. Treat load/benchmark testing as a separate governed activity.

Polling / pagination

The core Lodging flow is:

Shopping
   -> Price Check
   -> Booking
   -> Retrieve / Cancel

It is not a create/poll session model. Tokenized links carry the next transaction step. If a resource-list endpoint supports pagination, implement only that endpoint's contract rather than forcing generic pagination across Rapid.

Price Check / booking lifecycle

SHOPPED
   -> PRICE_CHECK
      -> MATCHED -> READY_TO_BOOK
      -> CHANGED -> USER_RECONFIRM_REQUIRED
      -> SOLD_OUT/UNAVAILABLE -> RE_SHOP_REQUIRED
   -> BOOKING
   -> CONFIRMED / UNKNOWN
   -> RETRIEVE / CANCEL / RECONCILE

Booking links are short-lived. A first-attempt HTTP 503 can indicate an expired booking link; re-run Price Check for a fresh link rather than blindly retrying the stale one.

Test/stub contract

Rapid's official test-header mechanism returns canned Shopping and Price Check responses. These fixtures are useful for contract tests covering parser/serializer behavior, price changes, sold-out state and 5xx handling. They are not evidence of real availability or production latency.

What does the integration own?

Rapid Lodging provides property catalog, geography, live shopping, price confirmation and booking lifecycle capabilities. This is more transaction-oriented than a simple affiliate deeplink integration.

Your system still owns:

• canonical property identity,
• supplier/property mappings,
• user search context,
• normalized offer model,
• persistence,
• payment/security boundaries,
• idempotency,
• timeout/retry policy,
• observability,
• booking reconciliation.

A strong provider API should not become your internal domain model.

What should the production flow look like?

Scheduled Content Sync
        |
        v
Local Property Catalog
        |
Traveler Search
        |
        +--> canonical destination/property resolution
        |
        v
Rapid Shopping
        |
        v
Normalized Offer Store / short cache
        |
Traveler selects rate
        |
        v
Rapid Price Check
        |
   +----+------+
   |           |
MATCHED      CHANGED / UNAVAILABLE
   |           |
   v           v
Booking Link  Update price / re-shop
   |
   v
Internal Booking Attempt
   |
   v
Rapid Booking
   |
   v
Itinerary / reservation identity
   |
   +--> retrieve
   +--> cancel/manage
   +--> reconciliation

The critical distinction is catalog state versus execution state.

Which data is durable and which is ephemeral?

Durable data

• Expedia property ID,
• canonical property mapping,
• region/geography mapping,
• content-snapshot metadata,
• normalized room/rate attributes,
• booking/itinerary ID,
• internal booking-attempt ID,
• price observations,
• booking lifecycle events.

Ephemeral data

• operational tokens from Shopping,
• booking link produced by Price Check,
• short-lived execution links,
• temporary request/session context.

Expedia's Booking documentation explicitly notes that the booking link returned after Price Check expires after a short period. It should therefore not be modeled as a permanent booking endpoint identifier.

How should property content be ingested?

Rapid's property catalog contains property identity and descriptive content such as property ID, name, address, contact information and star rating. Expedia recommends regular—typically daily—content refresh.

A local model may include:

properties
provider_properties
property_content_snapshots
property_amenities
property_images
provider_regions
provider_property_regions

Keep this invariant:

internal_property_id != expedia_property_id

The Expedia identifier is an external identity, not your canonical domain identity.

Why should geography be a separate boundary?

If destination search is directly coupled to Expedia's taxonomy, adding another supplier makes your search model provider-specific.

Prefer:

User destination
      |
Canonical destination
      |
Provider mappings
   +--+--------+
   |           |
Expedia     Provider B
Region ID   Region ID

This becomes increasingly important in a multi-supplier metasearch architecture.

What search context must be preserved?

Rapid Shopping uses stay dates, occupancy, property IDs and market context to return live rooms and rates. Provider limits and request constraints can change, so implementation should read current limits from official documentation rather than hard-code assumptions from an old guide.

A normalized internal request could look like:

{
  "checkIn": "2026-10-10",
  "checkOut": "2026-10-13",
  "rooms": [
    {
      "adults": 2,
      "children": []
    }
  ],
  "currency": "EUR",
  "travelerCountry": "DE",
  "language": "en-US",
  "propertyIds": ["..."]
}

The provider adapter translates this stable contract into Expedia-specific request syntax.

How should Shopping responses be normalized?

Shopping returns more than price. It includes room, refundability, cancellation penalties, fees, promotions and price breakdowns.

A normalized offer might preserve:

interface HotelOffer {
  provider: "expedia-rapid";
  providerPropertyId: string;
  providerRoomId?: string;
  providerRateId?: string;

  checkIn: string;
  checkOut: string;
  occupancy: Occupancy[];

  roomName: string;
  refundable: boolean;
  cancellation?: CancellationPolicy;

  baseAmount: number;
  taxAmount: number;
  mandatoryFeeAmount: number;
  totalAmount: number;
  currency: string;

  observedAt: string;
  sourcePayloadRef: string;
  priceCheckLink: string;
}

Keep the original payload or a durable source reference as well. Lossy normalization makes production debugging much harder.

Why is Price Check a transaction boundary?

Price or availability may change between Shopping and booking. Rapid Price Check verifies the selected offer close to the transaction.

Typical outcomes:

MATCHED

The price remains valid and a booking link is returned.

CHANGED

The amount changed. The traveler should see the new total.

UNAVAILABLE / re-shop

The selected rate is no longer bookable and Shopping must run again.

The Booking service should therefore accept a successful Price Check result, not an arbitrary old Shopping token.

What should happen when the price changes?

Silently booking the changed amount is risky.

A useful state machine is:

SELECTED
   |
PRICE_CHECK
   |
   +--> MATCHED --------> READY_TO_BOOK
   |
   +--> CHANGED --------> USER_RECONFIRM_REQUIRED
   |
   +--> UNAVAILABLE ----> RE_SHOP_REQUIRED

Persist both displayed and confirmed amounts for later reconciliation.

How should booking idempotency work?

Consider this failure:

1. your service sends a Booking request,
2. Expedia creates the reservation,
3. the response is lost during a network timeout,
4. your system assumes failure and sends another create request.

Blind retry can create duplicate reservations.

Create an internal booking attempt before calling Rapid:

booking_attempt
- id
- user/session
- provider
- offer_fingerprint
- displayed_amount
- confirmed_amount
- status
- created_at
- provider_itinerary_id

If state becomes unknown after a timeout, recover or retrieve the original outcome before issuing another create attempt.

What should the error taxonomy look like?

Avoid one generic “Expedia error.”

Example classes:

• AUTH_ERROR
• INVALID_SEARCH_CONTEXT
• NO_AVAILABILITY
• PRICE_CHANGED
• PRICE_CHECK_EXPIRED
• BOOKING_LINK_EXPIRED
• PAYMENT_REJECTED
• PROVIDER_4XX
• PROVIDER_5XX
• PROVIDER_TIMEOUT
• RATE_LIMIT
• BOOKING_STATE_UNKNOWN
• RETRIEVE_FAILED
• CANCEL_FAILED

These classes should drive retry behavior.

Which failures should be retried?

Usually retryable

• network timeout,
• selected 5xx responses,
• transient connection failures,
• some rate-limit conditions.

Do not blindly retry

• invalid occupancy,
• validation errors,
• changed price,
• unavailable rate,
• payment/business rejection,
• unknown booking state.

“Unknown” and “failed” are not the same state.

How should timeout budgets be separated?

Interactive operations need bounded deadlines.

Example:

Shopping       -> 1500-2500 ms budget
Price Check    -> strict user-facing budget
Booking        -> longer, bounded transaction budget
Retrieve       -> recovery/asynchronous capable
Content Sync   -> background retry policy

Actual values should be based on your latency distribution and user experience.

Why preserve the full price breakdown?

Flattening base price, taxes and property-payable fees into one total makes reconciliation difficult.

At minimum retain:

• displayed base,
• taxes,
• mandatory fees,
• property fees,
• total,
• currency,
• billable/display currency context.

Expedia documents market- and currency-specific price-display behavior, so normalization should preserve source semantics rather than reconstruct them later.

What should be monitored?

Shopping

• requests per search,
• success rate,
• empty-availability rate,
• p50/p95 latency,
• property coverage.

Price Check

• match rate,
• changed-price rate,
• unavailable rate,
• price-delta distribution.

Booking

• booking success rate,
• unknown-state rate,
• duplicate-prevented count,
• payment rejection,
• booking latency.

Post-booking

• retrieve success,
• cancellation success,
• reconciliation gaps,
• unmatched itineraries.

Provider monitoring should measure business-semantic health, not only HTTP uptime.

Where is the security boundary?

Booking flows carrying payment or PII should not expose provider credentials in browser code.

A backend service should:

• manage credentials,
• suppress sensitive fields from logs,
• apply request masking,
• keep an audit trail,
• enforce authorization,
• manage idempotency.

Logging full payment payloads is not a debugging strategy; it is a security problem.

Go-live checklist

• Is canonical property mapping complete enough?
• Is static content refresh scheduled?
• Is geography separated from provider taxonomy?
• Is full Shopping context preserved?
• Are source offer semantics retained?
• Is Price Check a required transaction boundary?
• Does CHANGED price require traveler reconfirmation?
• Is booking-link expiry handled?
• Are booking attempts idempotent?
• Is unknown-state recovery implemented?
• Is full price breakdown persisted?
• Are payment/PII logs masked?
• Is retry behavior error-class specific?
• Are Shopping/PriceCheck/Booking KPIs separate?
• Have retrieve/cancel reconciliation flows been tested?

2026 API audit notes

The current Rapid documentation reinforces three implementation boundaries:

• tokenized price_check links from Shopping are short-lived and should not be persisted for long-term reuse;
• when Price Check detects a change it can return updated price details plus a new booking link, so traveler reconfirmation remains a real transaction boundary;
• successful Booking responses provide follow-up links such as Retrieve and Cancel; treat these as provider lifecycle references and store them securely with the itinerary.

Current price-display fields such as property_inclusive also make it important not to flatten every amount into one total. Preserve base, taxes, Expedia/property-collected fees and request/billable currency semantics.

Rapid's current Postman collections and OpenAPI material are useful for request/response contract regression tests. Prefer local fixtures/schema tests in CI rather than live provider calls.

Meta Search takeaway

Implementing Expedia Rapid correctly is not about memorizing endpoint order. The important architecture is the separation of durable catalog data from ephemeral transaction state, revalidation of the selected offer through Price Check, and idempotent management of booking lifecycle. With those boundaries in place, Expedia-specific behavior stays inside an adapter rather than leaking across the entire product.

Companion capability boundary

Rapid Lodging separates durable Content/Geography data from live Shopping, Price Check, Booking and Manage Booking contracts. Keep these as distinct adapter capabilities with separate freshness, error and transaction-state policies rather than treating Rapid as one generic hotel endpoint.