Ellipse Gradient for Header

Booking.com Connectivity APIs Integration Guide

Connect approved hospitality systems with Booking.com to synchronize properties, rooms, rates, availability, restrictions, and reservations through HTTP-based Connectivity APIs.

Booking.com Connectivity APIs integration options at a glance

Booking.com Connectivity APIs provide HTTP-based system-to-system exchanges for approved connectivity partners and properties. Depending on the selected API product, operations may use structured XML and, where documented, JSON representations. Integrations commonly retrieve reservations and changes, publish availability, send rates and restrictions, and read property, room, and rate configuration. Selected operations support date ranges or multiple updates, but a universal asynchronous job framework is not confirmed. Access typically uses provisioned credentials, commonly HTTP Basic Authentication, together with property identifiers. Martini can schedule incremental retrieval, consume and expose APIs, transform XML or JSON, apply validation and idempotency rules, and orchestrate downstream updates.

Integration pointSupported by Booking.com Connectivity APIs?Common use casesHow Martini supports it
HTTP-based REST-style APIsLimitedBooking.com Connectivity APIs exchange property configuration, reservations, availability, rates, and restrictions over HTTP. Some interfaces are XML-oriented rather than conventional JSON REST.Martini can consume HTTP APIs from workflows, configure requests and authentication, parse XML or JSON, and map responses into downstream models.
Bulk / date-range updatesLimitedSelected availability, rate, and restriction operations support date ranges or multiple updates for calendar-style synchronization.Martini can build validated date-range payloads, orchestrate batches, process responses, and retry eligible failures.
Reservation retrieval and change queriesYesApproved partners can retrieve new, modified, or cancelled reservations using the filtering and incremental mechanisms documented for the selected API version.Martini can schedule retrieval, maintain a durable checkpoint, process pages or batches, and commit the checkpoint only after downstream success.
Webhooks / outbound callbacksNot confirmedA general webhook mechanism for reservation, inventory, rate, and property events was not confirmed. A partner-specific callback would require separate Booking.com arrangements.Martini can expose an API to receive a callback if Booking.com provisions one, but standard designs should use documented retrieval or change-query operations.
AuthenticationYesAccess is restricted to approved connectivity partners and properties and commonly uses provisioned HTTP credentials, often HTTP Basic Authentication, with property identifiers.Martini can store credentials in secure configuration, apply authentication to requests, and keep property identifiers separate from reusable workflow logic.
XML payloadsYesSome Connectivity API products and operations use structured XML for configuration, inventory, rate, restriction, or reservation exchanges.Martini can parse, validate, transform, and generate XML while preserving namespaces and optional fields required by the selected API.
JSON payloadsLimitedJSON representations may be available for relevant API products, but the format must be confirmed for each selected endpoint.Martini can process JSON when provided and transform it to canonical or target application models.
Database / analytics accessNoBooking.com does not expose direct database access through the Connectivity APIs. Reporting data must be retrieved through APIs and persisted elsewhere.Martini can write retrieved data to an application-owned database or analytics destination using supported database and API capabilities.

How Booking.com Connectivity APIs exposes data and business events

Booking.com HTTP APIs

Booking.com Connectivity APIs are HTTP-based and support system-to-system operations for property configuration, rooms, rates, availability, restrictions, and reservations. The selected API product determines the endpoint style and whether XML or JSON representations are used.

Martini implementation pattern

Martini implementation pattern: a workflow builds the authenticated request, sends it to the documented Booking.com operation, parses the response, maps the result to a canonical model, and routes failures for controlled handling.

Implementation sequence

Configure the approved Booking.com endpoint and property identifier
Retrieve credentials from secure Martini configuration
Build the XML or JSON request required by the selected operation
Send the authenticated HTTP request
Validate the response and map the returned object
Persist the result or route an error for review

Booking.com reservation retrieval

Reservation integrations generally retrieve new, modified, or cancelled bookings through documented retrieval or change-query mechanisms rather than relying on a general event stream.

Martini implementation pattern

Martini implementation pattern: a scheduled workflow uses a durable change timestamp, reservation identifier, or other documented filter, processes each page or batch idempotently, and commits the checkpoint only when downstream writes complete.

Implementation sequence

Start the scheduled incremental reservation workflow
Read the last successful synchronization checkpoint
Request the next Booking.com reservation page or change set
Validate reservation, property, room, date, and state fields
Create or update the downstream reservation idempotently
Store the checkpoint after successful downstream processing

Booking.com availability and rate updates

Booking.com supports selected availability, rate, and restriction operations, including date-range or multiple-item updates. These operations are useful for publishing PMS or channel-manager changes to Booking.com.

Martini implementation pattern

Martini implementation pattern: a workflow receives internal room-calendar changes, resolves Booking.com identifiers, validates dates and occupancy rules, constructs the supported batch payload, submits it, and records any rejected items for reconciliation.

Implementation sequence

Receive or retrieve internal availability and pricing changes
Resolve internal rooms and rates to Booking.com identifiers
Validate dates, occupancy, prices, and restrictions
Construct the supported date-range or multi-item payload
Submit the authenticated update to Booking.com
Record the response and retry or reconcile failed items

Booking.com partner callbacks

A general Booking.com webhook model covering all reservation, inventory, rate, and property events was not confirmed. A callback may exist only under a specific partner arrangement.

Martini implementation pattern

Martini implementation pattern: if Booking.com provisions a callback, Martini can expose a controlled API to receive it, validate the sender and payload, retrieve the authoritative resource when appropriate, and invoke the same idempotent processing workflow used for scheduled synchronization.

Implementation sequence

Confirm the callback arrangement and payload contract with Booking.com
Expose a secured Martini API endpoint
Validate the callback and property context
Retrieve authoritative Booking.com data when required
Process the notification idempotently
Return an appropriate response and monitor failures

Common Booking.com Connectivity APIs integration patterns

Pattern 1: Sync reservations to a property-management system

When to use this pattern

Use this pattern when a PMS must receive new, modified, and cancelled Booking.com reservations without repeatedly processing the complete reservation history. Incremental retrieval, stable identifiers, and checkpoint control are central to reliable processing.

Integration direction
Booking.com Connectivity APIs
Martini
Oracle OPERA Cloud
Example Mapping
Booking.com Connectivity APIs FieldCanonical FieldTarget Field
hotel_idpropertyIdhotelCode
reservation_idreservationIdconfirmationNumber
arrival_datecheckInDatearrivalDate
departure_datecheckOutDatedepartureDate
Martini implementation pattern

A scheduled Martini workflow requests the next reservation changes, validates property and room mappings, maps reservation state and guest data to the PMS model, and applies create, update, or cancellation rules. It uses the reservation identifier and modification state for idempotency, retries transient failures, and advances the checkpoint only after successful downstream processing.

Martini capabilities used
  • workflows
  • API consumption
  • scheduling
  • data mapping
  • business rules
  • error handling

Pattern 2: Publish availability from a PMS

When to use this pattern

Use this pattern when internal inventory changes must be sent to Booking.com across a date range. It is suitable for room closures, inventory adjustments, and routine availability calendar publication.

Integration direction
Cloudbeds
Martini
Booking.com Connectivity APIs
Example Mapping
Booking.com Connectivity APIs FieldCanonical FieldTarget Field
room_idroomIdroom_id
available_unitsavailableInventoryavailability
stay_datedatedate
property_idpropertyIdhotel_id
Martini implementation pattern

Martini receives or retrieves PMS inventory changes, resolves stable Booking.com room and property identifiers, validates date ranges and non-negative inventory, and submits supported date-range updates. The workflow records request and response context, avoids duplicate publication where possible, and routes rejected dates for reconciliation.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • validation
  • business rules
  • error handling

Pattern 3: Synchronize rates and restrictions

When to use this pattern

Use this pattern when a revenue-management or property-management application publishes prices, rate plans, minimum-stay rules, or arrival and departure restrictions to Booking.com.

Integration direction
Mews
Martini
Booking.com Connectivity APIs
Example Mapping
Booking.com Connectivity APIs FieldCanonical FieldTarget Field
rate_plan_idrateIdrate_id
pricenightlyPriceprice
min_losminimumLengthOfStaymin_length_of_stay
closed_to_arrivalclosedToArrivalclosed_to_arrival
Martini implementation pattern

A Martini workflow normalizes internal rate calendars, validates occupancy combinations and date ranges, applies precedence rules for conflicting restrictions, and submits the relevant Booking.com operations. It separates successful and failed items, retries temporary errors with backoff, and prevents the source system from marking the whole calendar complete after partial failure.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • validation
  • error handling

Pattern 4: Reconcile Booking.com property configuration

When to use this pattern

Use this pattern when a connectivity platform needs to detect changed rooms, rate plans, property settings, or identifier mismatches before they affect production synchronization.

Integration direction
Booking.com Connectivity APIs
Martini
PostgreSQL
Example Mapping
Booking.com Connectivity APIs FieldCanonical FieldTarget Field
hotel_idpropertyIdproperty_id
room_idroomIdbooking_room_id
rate_idrateIdbooking_rate_id
room_namedisplayNameroom_name
Martini implementation pattern

Martini periodically retrieves Booking.com configuration, compares it with an internal mapping store, and produces reconciliation outcomes for new, removed, or changed rooms and rates. The workflow does not treat Booking.com as a database; it persists the API response in an application-owned store and flags unmapped identifiers before outbound updates proceed.

Martini capabilities used
  • workflows
  • scheduling
  • API consumption
  • data mapping
  • business rules
  • database integration

Applications commonly integrated with Booking.com Connectivity APIs

Booking.com Connectivity APIs can be integrated with hospitality platforms and enterprise applications that manage reservations, inventory, distribution, guest operations, and financial reporting. The following are representative architecture patterns rather than claims of Booking.com-certified integrations.

Application Scenario Direction Martini Pattern
Cloudbeds Synchronize reservations, room inventory, rates, and restrictions between a property-management platform and Booking.com. Cloudbeds → Martini → Booking.com Connectivity APIs Martini retrieves incremental reservations, maps Cloudbeds identifiers to Booking.com property, room, and rate identifiers, and publishes validated availability and rate changes through scheduled workflows.
Oracle OPERA Cloud Deliver Booking.com reservations to the hotel PMS and publish availability, rates, and restrictions back to Booking.com. Booking.com Connectivity APIs → Martini → Oracle OPERA Cloud Martini orchestrates reservation retrieval, validates dates and room mappings, writes bookings to Oracle OPERA Cloud, and uses a separate workflow for date-range inventory and restriction updates.
Mews Keep reservations and inventory aligned between a cloud PMS and Booking.com. Mews → Martini → Booking.com Connectivity APIs Martini converts Mews room and rate changes into Booking.com payloads, batches supported date ranges, records responses, and retries transient failures without duplicating updates.
SiteMinder Coordinate channel distribution, rates, availability, restrictions, and reservation delivery. SiteMinder → Martini → Booking.com Connectivity APIs Martini provides the orchestration layer between distribution data and Booking.com, maintaining identifier mappings and applying business rules before publishing channel updates.
Guesty Synchronize reservations and property availability for short-term rental and property-management operations. Booking.com Connectivity APIs → Martini → Guesty A scheduled Martini workflow retrieves reservation changes, maps guest and stay data to Guesty, stores a checkpoint after successful processing, and routes rejected records for reconciliation.
Salesforce Create or update guest, account, service, or booking-related records for sales and guest-service workflows. Booking.com Connectivity APIs → Martini → Salesforce Martini retrieves or receives booking data through confirmed Booking.com mechanisms, normalizes guest and reservation fields, applies consent and deduplication rules, and calls Salesforce APIs.
NetSuite Transfer booking or revenue data for financial reconciliation, invoicing, and reporting. Booking.com Connectivity APIs → Martini → NetSuite Martini maps reservation, property, rate, and financial fields into NetSuite-oriented payloads, enriches them with internal accounting mappings, and retains failed records for replay.
Microsoft Dynamics 365 Synchronize customer, reservation, and service data with CRM or finance processes. Booking.com Connectivity APIs → Martini → Microsoft Dynamics 365 Martini schedules incremental Booking.com retrieval, transforms reservation data into Dynamics 365 entities, validates identifiers, and handles API failures through controlled retries and error queues.

How to build a Booking.com Connectivity APIs integration in Martini

Objective

Establish approved Booking.com partner access and configure the selected Connectivity API endpoint, property identifiers, and credentials without embedding secrets in workflow logic.

Instructions in Martini

  • Confirm the Booking.com partner and property authorization
  • Identify the selected API product and its XML or JSON contract
  • Store credentials and endpoint configuration in secure Martini configuration
  • Test authentication with a representative property request

Objective

Select a schedule or API-led entry point appropriate to the synchronization direction and Booking.com’s documented retrieval model.

Instructions in Martini

  • Use a scheduler for incremental reservation retrieval
  • Use an inbound API or application event for internal PMS changes
  • Do not assume a general Booking.com webhook exists
  • Define the required synchronization interval and checkpoint scope

Objective

Request reservation changes or configuration and receive availability, rate, restriction, or reservation payloads using the documented Booking.com operation.

Instructions in Martini

  • Build requests with the required property and filter parameters
  • Implement pagination or continuation exactly as documented
  • Capture response status, correlation data, and processing context
  • Preserve the checkpoint until the batch is successfully completed

Objective

Coordinate API calls, validation, mappings, downstream writes, and response handling as a maintainable Martini workflow.

Instructions in Martini

  • Separate retrieval, transformation, business validation, and target writes
  • Use reusable workflow logic for common reservation or calendar processing
  • Branch for new, modified, and cancelled reservations
  • Keep partial batch failures visible for replay or reconciliation

Objective

Convert Booking.com rooms, rates, dates, restrictions, inventory, and reservations into canonical and target application models.

Instructions in Martini

  • Map stable identifiers rather than room or rate names alone
  • Transform XML or JSON into the internal model
  • Normalize property-local dates and timestamps carefully
  • Retain required optional and unknown fields where forward compatibility matters

Objective

Prevent invalid or unsafe updates before they reach Booking.com or downstream systems.

Instructions in Martini

  • Validate property, room, rate, occupancy, and date relationships
  • Apply idempotency using reservation and operation identifiers
  • Check conflicting restrictions and unsupported combinations
  • Classify business rejections separately from transient API failures

Common Booking.com Connectivity APIs data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
Property / hotelIdentifies the accommodation establishment connected to Booking.com and anchors property-level configuration and operations.Property-management systems, channel managers, data warehousesMartini maps the Booking.com property or hotel identifier to an internal property key and validates authorization before processing child objects.
RoomRepresents a sellable room or accommodation unit associated with a property.Oracle OPERA Cloud, Cloudbeds, Mews, SiteMinderMartini maintains stable identifier mappings, normalizes room attributes, and rejects updates for unmapped or unauthorized rooms.
RateRepresents a pricing product or rate plan applied to a room, including pricing and occupancy rules.PMS platforms, revenue-management systems, channel managers, finance systemsMartini maps rate identifiers, validates occupancy and date ranges, and transforms internal prices and rate rules into Booking.com payloads.
Availability / inventoryCommunicates the number of units available for sale over one or more dates.PMS platforms, channel managers, reservation systemsMartini converts internal inventory calendars into supported date-range updates, applies validation, and records endpoint responses.
RestrictionControls selling conditions such as minimum or maximum length of stay, closed-to-arrival, and closed-to-departure.PMS platforms, revenue-management systems, channel managersMartini applies business rules for conflicting restrictions, validates date ranges, and sequences restriction updates with related rates and availability.
Reservation / bookingContains a guest booking, stay dates, guest details, rooms, prices, and modification or cancellation information.Oracle OPERA Cloud, Cloudbeds, Mews, Guesty, Salesforce, NetSuiteMartini retrieves incremental changes, maps reservation states and identifiers, performs idempotency checks, writes downstream records, and advances checkpoints after success.

Authentication and security considerations

Approved partner access

Booking.com Connectivity API access is provisioned for approved connectivity partners and properties. Partner agreements, property authorization, endpoint access, and credentials should be confirmed during onboarding.

Credential protection

Connectivity implementations commonly use Booking.com-provided HTTP credentials, often Basic Authentication, together with property identifiers. Store these values in Martini secure configuration or secrets facilities rather than in mappings, payload templates, or source-controlled workflow definitions.

Least-privilege handling

  • Scope credentials and workflows to the properties and API products they are authorized to access.
  • Keep property identifiers and endpoint configuration environment-specific.
  • Record operational metadata without exposing authentication values in logs.

Operational considerations for Booking.com Connectivity APIs integrations

Rate limits and batching

Booking.com may apply partner- or endpoint-specific limits. Use supported date-range operations, avoid unnecessary polling, and apply backoff for throttling or temporary errors.

Pagination and checkpoints

Reservation and configuration responses may contain multiple items. Implement the selected API’s pagination or continuation rules and commit a synchronization checkpoint only after the complete page or batch is processed successfully.

Idempotency and state

Use stable reservation and operation identifiers to prevent duplicate downstream bookings or unintended repeated updates. Treat created, modified, and cancelled reservation states explicitly.

Dates and schemas

Preserve property-local stay dates and distinguish them from creation or modification timestamps. For XML operations, handle namespaces, schema validation, escaping, and optional elements carefully.

Testing and reconciliation

Test representative reservations, cancellations, room mappings, rate changes, restrictions, partial failures, and retries. Record response context and run reconciliation workflows to identify missed or rejected updates.

Why use Martini instead of scripts or point-to-point integrations?

Orchestration instead of point-to-point code

Booking.com synchronization typically spans reservation retrieval, identifier mapping, PMS or channel-manager updates, inventory publication, rate rules, and reconciliation. Martini keeps these steps in explicit workflows rather than distributing them across brittle scripts.

Reusable integration logic

Martini can centralize authentication, XML and JSON transformation, validation, idempotency, retry handling, checkpoint management, and downstream API calls so that multiple properties or target systems follow consistent rules.

Operational control

Schedules, workflow execution, error paths, logging, and environment-specific secrets provide a maintainable operating model for incremental reservation synchronization and date-range publishing.

Frequently asked questions

How can Booking.com Connectivity APIs be integrated with enterprise systems?

Approved connectivity partners can use Booking.com’s HTTP-based Connectivity APIs to exchange property, room, rate, availability, restriction, and reservation data. Integrations commonly retrieve reservation changes incrementally and publish date-range inventory, rate, or restriction updates. The selected API determines whether XML or JSON is used and which authentication and filtering parameters apply.

Can Martini integrate with Booking.com Connectivity APIs?

Yes. Martini can consume the applicable Booking.com Connectivity APIs, securely configure their provisioned credentials, schedule incremental reservation retrieval, transform XML or JSON payloads, and orchestrate updates to PMS, channel-management, CRM, finance, or database systems. A general Booking.com webhook capability is not confirmed.

Do I need a connector to integrate Booking.com Connectivity APIs with Martini?

No. A dedicated Booking.com connector is not required. Martini can use Booking.com’s documented HTTP-based Connectivity APIs, authentication methods, reservation retrieval mechanisms, and supported date-range operations through workflows and API services.

Is there any extra Lonti cost to integrate Booking.com Connectivity APIs with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Booking.com Connectivity APIs. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Booking.com, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.

Which Booking.com integration methods should an architecture use?

Use the documented HTTP Connectivity API for the selected Booking.com product. Reservation synchronization should normally use the documented retrieval or change-query mechanism, while availability, rates, and restrictions can use supported date-range or multi-item operations. Do not assume GraphQL or SOAP support, and confirm whether each operation uses XML or JSON.

Does Booking.com provide webhooks, callbacks, GraphQL, or SOAP?

A general webhook or outbound callback model for Connectivity API events was not confirmed. A partner-specific callback may be possible only if Booking.com provisions it separately. No Booking.com Connectivity GraphQL API was confirmed, and the reviewed documentation does not support SOAP. Martini can receive a callback if a specific partner arrangement provides one.

How does reservation synchronization work with Booking.com Connectivity APIs?

A scheduled Martini workflow can request new, modified, or cancelled reservations using the selected API’s documented filters or change-query mechanism. It stores a durable checkpoint, processes pages or batches idempotently using stable reservation identifiers and modification state, writes successful results to the target system, and advances the checkpoint only after downstream processing completes.

How does Martini handle Booking.com mapping, errors, retries, and API exposure?

Martini can map Booking.com property, room, rate, availability, restriction, and reservation models into canonical and target formats, including XML and JSON transformations. Workflows can validate data, apply business rules, retry transient failures with backoff, prevent duplicates, and route rejected items for reconciliation. Martini can also expose an API façade for internal applications or a partner-specific callback, subject to the confirmed Booking.com contract.