.png)
Expedia Group Rapid API Integration Guide
Connect lodging search, price validation, booking, itinerary management, and selected reservation notifications with enterprise systems through signed Rapid REST APIs.
Expedia Group Rapid API integration options at a glance
Expedia Group Rapid API provides HTTPS REST APIs for lodging property content, availability shopping, price checks, booking, itinerary retrieval, cancellation, and selected itinerary notifications. Requests generally use JSON and require partner credentials, including an API key, shared secret, timestamp-based signature, and operation-specific headers. Martini can consume these endpoints through workflows, calculate or inject signed authentication values, validate and transform payloads, and expose an internal REST API for booking applications or notification intake. Selected reservation notifications can trigger reconciliation workflows, while scheduled workflows can retrieve and compare itinerary state. Rapid does not provide confirmed general-purpose bulk, file, database, GraphQL, or SOAP integration mechanisms.
| Integration point | Supported by Expedia Group Rapid API? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Rapid REST APIs cover property content, property search and availability shopping, price checks, booking, itinerary retrieval, cancellation, and other lodging operations. | Martini can consume Rapid REST endpoints from workflows, generate reusable API assets from definitions where applicable, map JSON payloads, and expose internal REST APIs for downstream applications. |
| Webhooks / outbound callbacks | Limited | Rapid provides itinerary notification capabilities for selected reservation-related events, subject to partner account and notification-product enablement. | Martini can expose a REST API to receive notifications, validate the request, retrieve authoritative itinerary state, and trigger idempotent downstream processing. |
| Authentication | Yes | Rapid uses partner API credentials, including an API key, shared secret, current Unix timestamp, and a request signature, with operation-specific headers such as Authorization and Customer-Ip where required. | Martini can store credentials as environment-specific secrets, calculate or inject signed authentication values, and apply them to outbound REST requests. |
| JSON payloads | Yes | Rapid REST resources and responses are generally exchanged as JSON for lodging content, availability, rates, bookings, and itineraries. | Martini can parse, validate, map, transform, and route JSON between Rapid and internal canonical models or target applications. |
| Price checks and booking orchestration | Yes | Rapid booking flows use a staged process: shop, retain the selected offer, price check, submit the reservation, and retrieve or reconcile the resulting itinerary. | Martini workflows can coordinate the stages, apply business rules, persist correlation and itinerary identifiers, and distinguish recoverable changes from definitive failures. |
| Scheduled synchronization | Yes | Scheduled retrieval and reconciliation can identify missed notifications, changed itinerary status, cancellation differences, and downstream processing gaps. | Martini scheduler-triggered workflows can retrieve selected itineraries, compare state, update target systems, and create exception outputs. |
| Bulk / async / batch APIs | Not confirmed | Rapid is primarily designed for online API transactions; a general-purpose bulk or asynchronous batch API was not confirmed. | Martini can implement pagination, controlled concurrency, and scheduled reconciliation without representing these as a Rapid bulk API. |
| File / attachment APIs | No | No general Rapid file import/export or attachment API was confirmed; Rapid resources are exchanged through API payloads. | Martini can process files for adjacent systems when required, but should use Rapid REST APIs for Rapid content, rates, bookings, and itineraries. |
| Database access | No | Expedia Group does not expose direct database access as part of the Rapid integration model. | Martini should consume documented Rapid APIs and use its own permitted persistence or target-system APIs for durable state and reconciliation. |
How Expedia Group Rapid API exposes data and business events
Expedia Group Rapid API REST APIs
Rapid API is primarily an HTTPS REST platform for property content, availability shopping, price checks, booking, itinerary retrieval, and cancellation. Responses are generally JSON, and access depends on enabled partner products and credentials.
Martini implementation pattern
Martini consumes Rapid endpoints from workflows, builds signed requests from environment-specific secrets, validates responses, and maps Rapid objects into internal or downstream models. A Martini REST API can provide a stable internal contract to booking applications while workflows handle Rapid-specific sequencing and error behavior.
Implementation sequence
Expedia Group Rapid API itinerary notifications
Rapid supports itinerary notifications for selected reservation-related events when the relevant notification capability is enabled for the partner account. These notifications are not a universal event stream for every Rapid object or lodging event.
Martini implementation pattern
A Martini REST API receives and validates the notification, then a workflow treats it as a signal rather than the complete reservation state. The workflow retrieves the current Itinerary from Rapid, applies idempotent mapping, and updates downstream systems while retaining a reconciliation path for delayed, duplicated, or out-of-order messages.
Implementation sequence
Rapid booking and price checks
Rapid booking is a multi-stage transaction in which an application shops for an offer, retains the selected Rate or token, performs a price check, submits the reservation, and stores the resulting Itinerary identifier. Rates, taxes, fees, and policies can change between stages.
Martini implementation pattern
Martini orchestrates the booking state machine and separates transport retries from business retries. It performs the required price validation, applies traveler and policy rules, submits the booking once the offer remains valid, and reconciles an uncertain outcome before considering a retry.
Implementation sequence
Scheduled itinerary reconciliation
Scheduled synchronization is useful for detecting missed notifications, cancellation or modification differences, and downstream processing gaps. Rapid does not provide a confirmed general-purpose bulk export, so reconciliation should use controlled API retrieval.
Martini implementation pattern
A Martini scheduler starts a workflow that retrieves selected itineraries or work items, compares Rapid state with the internal reservation model, and emits updates or exceptions. Pagination, rate controls, checkpointing, and bounded concurrency prevent reconciliation from overwhelming the partner API or runtime.
Implementation sequence
Common Expedia Group Rapid API integration patterns
Pattern 1: Aggregate lodging search and availability
When to use this pattern
Use this pattern when a booking application needs a stable internal search contract or wants to combine Rapid lodging inventory with other travel sources. The workflow should validate dates and occupancy, retrieve paginated results, normalize Property, Room, Rate, and Availability data, and apply internal filtering before returning results.
Integration direction
Example Mapping
| Expedia Group Rapid API Field | Canonical Field | Target Field |
|---|---|---|
| property_id | property.sourceId | lodging.propertyId |
| room | room.description | lodging.rooms[].name |
| rate | rate.totalAmount | lodging.rooms[].offers[].total |
| cancellation | rate.cancellationPolicy | lodging.rooms[].offers[].cancellationPolicy |
Martini implementation pattern
A Martini REST API accepts destination, dates, occupancy, and filters. A workflow calls Rapid shopping endpoints, handles pagination and controlled concurrency, maps JSON into a canonical search response, applies commercial or eligibility rules, and returns a consistent contract. Transient failures are retried selectively, while partial results and provider errors are surfaced according to the application's search policy.
Martini capabilities used
- APIs
- workflows
- API consumption
- data mapping
- JSON handling
- business rules
- error handling
Pattern 2: Orchestrate price-checked reservations
When to use this pattern
Use this pattern for booking applications that must protect against changes in availability, price, taxes, fees, or cancellation conditions between shopping and reservation creation. It is appropriate for a transactional workflow that needs durable state and careful handling of uncertain responses.
Integration direction
Example Mapping
| Expedia Group Rapid API Field | Canonical Field | Target Field |
|---|---|---|
| property_id | reservation.propertyId | booking.propertyId |
| rate | reservation.selectedRateId | booking.rateId |
| occupancy | reservation.guests | booking.travelers |
| itinerary_id | reservation.providerConfirmationId | booking.rapidItineraryId |
Martini implementation pattern
Martini receives the selected offer, validates Guest and booking data, performs the Rapid price check, and submits the reservation only when the current offer satisfies business rules. The workflow persists a correlation key and state transition before and after the booking call. A timeout or ambiguous response triggers itinerary lookup and reconciliation rather than an unguarded duplicate booking retry.
Martini capabilities used
- workflows
- API consumption
- secrets management
- data mapping
- business rules
- durable state
- error handling
Pattern 3: Process itinerary notifications
When to use this pattern
Use this pattern when the partner account has selected Rapid itinerary notifications enabled and internal systems need timely reservation updates. Notifications should be treated as triggers to retrieve authoritative state, not as complete reservation payloads.
Integration direction
Example Mapping
| Expedia Group Rapid API Field | Canonical Field | Target Field |
|---|---|---|
| itinerary_id | reservation.providerConfirmationId | Salesforce.bookingReference |
| status | reservation.status | Salesforce.bookingStatus |
| cancellation | reservation.cancellation | ServiceNow.exceptionDetails |
| notification_id | event.processingKey | integration.processedEventKey |
Martini implementation pattern
A Martini REST API receives the notification and validates its authentication and identifiers. The workflow checks the processing key, retrieves the current Itinerary from Rapid, maps reservation changes, and updates Salesforce or ServiceNow idempotently. Duplicate and out-of-order notifications are recorded without replaying downstream side effects.
Martini capabilities used
- REST APIs
- webhook consumption
- workflows
- data mapping
- idempotency
- business rules
- error handling
Pattern 4: Reconcile reservations on a schedule
When to use this pattern
Use this pattern as a consistency control for important reservations or when notification coverage is incomplete. It detects missed notifications, delayed processing, and differences in cancellation or modification status without relying on a confirmed Rapid bulk API.
Integration direction
Example Mapping
| Expedia Group Rapid API Field | Canonical Field | Target Field |
|---|---|---|
| itinerary_id | reservation.providerConfirmationId | reconciliation.providerItineraryId |
| status | reservation.status | NetSuite.bookingStatus |
| cancellation | reservation.cancellationAmount | NetSuite.refundOrCancellationAmount |
| last_updated | reservation.providerUpdatedAt | reconciliation.lastObservedAt |
Martini implementation pattern
A scheduled Martini workflow loads a bounded worklist, retrieves current itineraries with controlled rate usage, compares provider and internal state, and applies only approved changes. It stores checkpoints, emits exception records for mismatches, and retries transient reads while avoiding repeated writes through correlation and state checks.
Martini capabilities used
- scheduler triggers
- workflows
- API consumption
- data mapping
- database integration
- business rules
- monitoring
- error handling
Applications commonly integrated with Expedia Group Rapid API
Rapid API can be placed behind an enterprise orchestration layer that connects lodging transactions with customer, service, property-management, finance, payment, and travel applications. The following are practical integration targets; they are architecture patterns rather than confirmed Rapid-native partnerships and depend on the adjacent application's own APIs and commercial terms.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize traveler profiles, corporate travel opportunities, booking status, and service context. | Expedia Group Rapid API → Martini → Salesforce | Martini workflows retrieve or receive itinerary data, normalize Guest and Itinerary fields, apply customer-matching rules, and create or update Salesforce objects. Salesforce can also call a Martini REST API to initiate search or booking requests. |
| ServiceNow | Create support cases or operational records for failed bookings, cancellations, payment issues, and reservation exceptions. | Expedia Group Rapid API → Martini → ServiceNow | A Martini notification or reconciliation workflow retrieves authoritative itinerary state, maps reservation exceptions to ServiceNow records, and uses correlation identifiers to prevent duplicate cases. |
| Oracle OPERA Cloud | Reconcile externally booked lodging reservations with property-management workflows where the operating model requires it. | Expedia Group Rapid API → Martini → Oracle OPERA Cloud | Martini maps Rapid Property, Room, Rate, Guest, and Itinerary data to the OPERA Cloud model, applies property and booking-status rules, and routes rejected or incomplete updates for review. |
| SiteMinder | Coordinate reservation or availability information in organizations that use SiteMinder alongside external distribution channels. | Expedia Group Rapid API → Martini → SiteMinder | Martini orchestrates the relevant APIs on both sides, normalizes lodging identifiers and rate information, and applies controlled synchronization rules to avoid conflicting inventory ownership. |
| NetSuite | Send booking, cancellation, commission, and reconciliation data into finance and ERP processes. | Expedia Group Rapid API → Martini → NetSuite | A Martini workflow retrieves completed or changed itineraries, maps financial and reservation fields, applies accounting classifications, and writes results to NetSuite with retry and exception handling. |
| Stripe | Coordinate payment authorization, capture, refund, or payment status with a booking workflow where a separate payment provider is required. | Booking application → Martini → Stripe | Martini coordinates payment calls and Rapid booking steps, performs the required Rapid price check, persists a booking correlation identifier, and routes uncertain payment or reservation states to reconciliation rather than blindly retrying. |
| Zendesk | Provide reservation and itinerary context to customer-support agents and synchronize support cases. | Expedia Group Rapid API → Martini → Zendesk | Martini retrieves current itinerary details after a notification or support request, redacts sensitive fields where appropriate, and maps booking status and policy details into Zendesk tickets or customer context. |
| Amadeus | Combine lodging and other travel search capabilities from multiple travel APIs behind a common orchestration layer. | Amadeus → Martini → Expedia Group Rapid API | Martini calls both REST APIs, normalizes Property, Room, Rate, Availability, and itinerary structures, applies source-prioritization rules, and exposes a unified internal search or booking API. |
How to build a Expedia Group Rapid API integration in Martini
Objective
Establish the Rapid API connection using partner credentials and environment-specific configuration for sandbox or production.
Instructions in Martini
- Store the API key and shared secret in Martini secrets or protected environment configuration.
- Implement the timestamp-based request signature required by Rapid.
- Configure required headers such as Authorization, Accept, User-Agent, and Customer-Ip where the operation requires them.
- Keep sandbox and production credentials and endpoints separated.
Objective
Select the event, API request, or schedule that starts each integration workflow.
Instructions in Martini
- Expose a Martini REST API for booking applications or Rapid itinerary notifications.
- Use a workflow trigger for inbound requests and notification processing.
- Use a scheduler for reservation reconciliation and controlled content retrieval.
- Assign a durable correlation identifier to booking and notification flows.
Objective
Call the appropriate Rapid operation and obtain current provider state before making downstream decisions.
Instructions in Martini
- Call property content, shopping, price-check, booking, itinerary, or cancellation endpoints as required.
- Process pagination explicitly and preserve search or reconciliation criteria.
- Retrieve the current Itinerary after a notification rather than assuming the notification is authoritative.
- Apply request throttling and bounded concurrency.
Objective
Coordinate Rapid's multi-stage lodging transaction and the surrounding enterprise process in a maintainable Martini workflow.
Instructions in Martini
- Model shopping, price validation, booking, confirmation, cancellation, and reconciliation as explicit states.
- Separate transport retries from business retries.
- Check for an existing booking state before retrying an uncertain booking request.
- Route exceptions and manual-review cases separately from successful processing.
Objective
Convert Rapid JSON structures into canonical reservation, lodging, customer, finance, or support models.
Instructions in Martini
- Map Property, Room, Rate, Availability, Itinerary, and Guest fields explicitly.
- Normalize identifiers, dates, monetary values, occupancy, cancellation policies, and status values.
- Preserve source identifiers and rate policy details needed for reconciliation and customer communication.
- Redact or omit sensitive Guest fields when writing logs or downstream records.
Objective
Protect booking integrity and enforce organization-specific commercial, eligibility, and operational policies.
Instructions in Martini
- Perform the required Rapid price check before submitting a reservation.
- Validate dates, occupancy, Guest data, selected Rate, and cancellation conditions.
- Apply source-prioritization or filtering rules when combining Rapid with other travel APIs.
- Use idempotency and state checks before creating bookings or downstream updates.
Common Expedia Group Rapid API data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Property | Represents a hotel or lodging property used in search, content retrieval, availability, and booking operations. | Booking applications, Oracle OPERA Cloud, SiteMinder, Salesforce | Martini maps Rapid property identifiers, content, location, and policy fields into a canonical lodging model and preserves source identifiers for correlation. |
| Room | Represents a sellable room type or configuration, including occupancy, amenities, bed configuration, and room-level content. | Booking applications, Oracle OPERA Cloud, SiteMinder | Martini transforms room descriptions and occupancy attributes, validates required fields, and applies property and room matching rules. |
| Rate | Represents a bookable pricing and policy offer associated with a Room, including cancellation rules, taxes, fees, payment terms, inclusions, and restrictions. | Booking applications, finance platforms, customer-service applications | Martini preserves rate and policy details, normalizes monetary values and cancellation conditions, and ensures the selected offer is revalidated through the price-check step. |
| Availability | Represents current lodging inventory and pricing results for requested dates, occupancy, destinations, or property identifiers. | Booking applications, travel portals, internal search APIs | Martini handles pagination and result limits, maps availability into a normalized response, applies filtering or commercial rules, and controls request concurrency. |
| Itinerary | Represents the booked lodging reservation and its lifecycle, including identifiers, traveler details, property information, stay dates, status, and cancellation information. | Salesforce, ServiceNow, NetSuite, Zendesk, Oracle OPERA Cloud | Martini stores Rapid itinerary identifiers, retrieves authoritative state after notifications, maps lifecycle changes, and applies idempotent updates and reconciliation. |
| Guest | Represents the traveler or occupant associated with a booking and supplies information needed for reservation creation and itinerary management. | Booking applications, Salesforce, Zendesk, property-management systems | Martini validates and maps Guest fields, restricts sensitive logging, applies retention and redaction rules, and routes only the required information to each target. |
Authentication and security considerations
Signed partner authentication
Rapid API generally uses an API key, shared secret, current Unix timestamp, and request signature rather than a general OAuth authorization flow. Martini can keep credentials in environment-specific secrets and calculate or inject the required signature for outbound requests.
Credential and data protection
- Separate sandbox and production credentials and configuration.
- Restrict access to API keys, shared secrets, and booking workflows.
- Protect Guest and traveler information with controlled access, redacted logs, and appropriate retention.
- Use encrypted transport and the security controls of the Martini deployment environment.
Operational considerations for Expedia Group Rapid API integrations
Traffic and pagination
Rapid usage is subject to partner-specific limits and commercial terms. Apply throttling, bounded concurrency, backoff for transient failures, explicit pagination, maximum page counts, and checkpointing for longer processes.
Booking integrity
Rates, taxes, fees, availability, and cancellation conditions can change between shopping and booking. Perform the required price check, retain a business correlation identifier, and reconcile uncertain booking outcomes before retrying.
Notifications and reconciliation
Selected itinerary notifications can be duplicated, delayed, or out of order. Retrieve authoritative itinerary state, make downstream writes idempotent, and use scheduled reconciliation to detect missed updates.
Testing and observability
Test signing, identifiers, price changes, booking and cancellation behavior, notification delivery, and error responses separately in sandbox and production approval contexts. Correlate workflow executions with endpoint names, timestamps, itinerary identifiers, status codes, and retry counts without logging complete Guest or payment payloads.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate the complete booking lifecycle
Rapid booking is a multi-stage process involving shopping, price validation, reservation creation, itinerary retrieval, and possible cancellation or reconciliation. Martini workflows keep these states and business rules explicit instead of scattering them across scripts.
Separate provider and enterprise models
Martini maps Rapid Property, Room, Rate, Availability, Guest, and Itinerary objects into canonical models and target-specific structures. This supports downstream applications without forcing each application to understand Rapid-specific payloads.
Improve reliability and maintainability
Reusable workflows, protected secrets, validation, controlled retries, idempotency checks, notification handling, and scheduled reconciliation provide operational controls that are difficult to maintain consistently in point-to-point scripts.
Provide stable internal APIs
Martini can expose a controlled REST API for booking applications and notification intake while keeping Rapid authentication, request signing, transformation, and provider-specific sequencing behind the integration boundary.
Frequently asked questions
Rapid API is primarily integrated through HTTPS REST APIs using JSON for property content, availability shopping, price checks, booking, itinerary retrieval, and cancellation. Selected itinerary notifications can support reservation updates, while scheduled API retrieval can provide reconciliation. Authentication generally uses an API key, shared secret, timestamp, and request signature.
Yes. Martini can consume Rapid REST APIs from workflows, store and use the required partner credentials, orchestrate shopping and booking sequences, map Rapid JSON payloads, and expose a REST API for selected itinerary notifications. A dedicated native Martini connector is not documented in the supplied materials.
No. A dedicated Expedia Group Rapid API connector is not required. Martini can use Rapid's confirmed REST APIs, selected itinerary notification endpoints, signed authentication model, and JSON payloads to implement the integration.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Expedia Group Rapid API. The integration uses the provisioned capacity of the Martini environment. Separate costs may apply from Expedia Group, infrastructure providers, payment providers, or other third parties depending on subscriptions, usage, and deployment model.
Use Rapid's REST APIs for property content, shopping, price checks, booking, itinerary retrieval, and cancellation. Use selected itinerary notifications when enabled for the partner account, but retrieve the authoritative Itinerary after receiving a notification. GraphQL and SOAP were not confirmed as current Rapid integration methods, and no general-purpose bulk or file API was confirmed.
Rapid provides itinerary notification capabilities for selected reservation-related events. Coverage is not a universal event stream for all Rapid objects or lodging events and should be confirmed for the partner account. Martini can receive the notification through an API, validate it, retrieve current itinerary state, and process the update idempotently.
Real-time-style synchronization can begin with a selected itinerary notification followed by an itinerary retrieval. Scheduled reconciliation can retrieve selected itineraries, compare provider and internal state, detect missed notifications or changes, and update downstream systems. Pagination, checkpoints, rate controls, and correlation identifiers are important because a general Rapid bulk API was not confirmed.
Martini can map Rapid Property, Room, Rate, Availability, Guest, and Itinerary structures into canonical models and apply validation and business rules. Workflows can use controlled retries for transient failures, but booking requests should not be blindly retried after a timeout. Durable correlation keys, itinerary lookups, state checks, redacted logging, and reconciliation help prevent duplicate bookings and downstream updates.
Related Martini documentation
Connect Expedia Group Rapid API with Martini
Use Martini to orchestrate Rapid lodging APIs, signed authentication, booking workflows, itinerary notifications, and reconciliation across your enterprise systems.