.png)
Sabre Integration Guide
Connect Sabre travel APIs with booking, reservation, customer, and operational systems through Martini workflows and APIs.
Sabre integration options at a glance
Sabre primarily integrates through REST APIs for air shopping, booking, passenger records, ticketing, hotel, car, and related travel services. These APIs commonly use JSON and OAuth 2.0 client-credentials authentication, while some services continue to use SOAP and XML. Selected products may support asynchronous processing or product-specific notifications, but a universal webhook or bulk API should not be assumed. Martini can authenticate securely, orchestrate Sabre calls, normalize travel payloads, expose internal REST APIs, and persist selected results in downstream systems. Certification and production environments should be configured separately, with account, PCC, entitlement, pagination, retry, and reconciliation rules applied per Sabre product.
| Integration point | Supported by Sabre? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Air shopping, booking, PNR operations, ticketing, hotel and car content, and related travel services. REST payloads are commonly JSON-oriented, although service-specific formats must be confirmed. | Martini can consume Sabre REST APIs from workflows, transform responses, apply business rules, and expose normalized results through Martini APIs. |
| SOAP APIs | Limited | Legacy, agency, reservation, or specialized Sabre Web Services that remain necessary when an equivalent REST operation is unavailable. | Martini can consume applicable Sabre SOAP services and transform XML payloads, while preserving required namespaces, headers, sessions, and fault handling. |
| Authentication | Yes | OAuth 2.0 client credentials is the common REST pattern, using Sabre-issued client credentials, bearer tokens, environment settings, and account or PCC entitlements. | Martini can keep credentials in secrets or protected configuration, obtain and renew tokens centrally, and separate certification from production settings. |
| Webhooks / outbound callbacks | Not confirmed | A universal Sabre webhook facility for reservation, ticketing, hotel, and shopping events was not confirmed. Product-specific notifications or queues may exist. | Martini can receive webhook-style requests where the relevant Sabre product explicitly provides them; otherwise scheduled retrieval or application-triggered workflows should be used. |
| Bulk / async / batch APIs | Limited | Selected Sabre products may offer asynchronous or specialized processing, but a universal bulk API for all travel objects was not confirmed. | Martini can orchestrate product-specific asynchronous calls, persist transaction state, and process result windows or continuation values where documented. |
| File / attachment APIs | Not confirmed | No general Sabre file or attachment API was confirmed. Itinerary or ticket documents require product-specific verification. | Martini can process a confirmed file response or download operation when supplied by the selected Sabre service, but should not assume a general file interface. |
| Database / analytics access | No | Direct access to Sabre operational reservation or travel-content databases is not a normal integration pattern. | Martini can consume Sabre APIs or authorized reporting and export interfaces and write selected transformed data to supported downstream databases. |
| JSON and XML payloads | Yes | REST services commonly return JSON, while SOAP and some legacy or specialized services use XML. | Martini can map, validate, and transform both JSON and XML representations into versioned internal travel models. |
How Sabre exposes data and business events
Sabre REST APIs
Sabre REST APIs are the principal modern integration mechanism for air shopping, booking, PNR operations, ticketing, hotel, car, and related travel services. Responses are commonly JSON-oriented, but the exact schema and operation depend on the Sabre product.
Martini implementation pattern
Martini implementation pattern: a workflow obtains or reuses an OAuth access token, calls the required Sabre REST operation, validates the response, maps it into a canonical travel model, applies business rules, and returns or persists the result. Product-specific pagination, entitlements, throttling, and transaction semantics are configured explicitly.
Implementation sequence
Sabre SOAP APIs
Sabre SOAP and XML services remain relevant for legacy or specialized agency, reservation, and back-office workflows where a suitable REST operation is unavailable or an existing implementation depends on SOAP.
Martini implementation pattern
Martini implementation pattern: a workflow constructs the required XML request, namespaces, security headers, and session information, invokes the Sabre SOAP service, separates SOAP faults from transport errors, and transforms the XML response for downstream processing.
Implementation sequence
Sabre Authentication
Sabre REST APIs commonly use OAuth 2.0 client credentials with a client ID, client secret, bearer token, environment endpoint, and account or PCC permissions. Certification and production configurations are typically distinct.
Martini implementation pattern
Martini implementation pattern: credentials and environment values are stored in protected configuration, a reusable workflow or service obtains tokens, and calling workflows reuse valid tokens until renewal is required. SOAP security and session requirements are handled separately where applicable.
Implementation sequence
Product-specific notifications
A universal Sabre webhook facility for all booking, reservation, ticketing, hotel, and air-shopping events was not confirmed. Selected products or customer arrangements may provide asynchronous notifications, queues, or other event-specific mechanisms.
Martini implementation pattern
Martini implementation pattern: first verify the notification mechanism for the specific Sabre product and account. If available, Martini can receive and validate the callback, retrieve current details when necessary, and process the event idempotently. If unavailable, a scheduled retrieval workflow or application-originated trigger provides the synchronization path.
Implementation sequence
Product-specific asynchronous processing
Some Sabre products may support asynchronous or specialized processing, but a universal bulk API covering all Sabre business objects was not confirmed. Large workloads should follow the selected API's search, reporting, or transaction model.
Martini implementation pattern
Martini implementation pattern: the workflow submits a supported operation, stores the transaction or continuation identifier, polls or retrieves the result according to Sabre guidance, and publishes completed results while handling timeouts and partial failures.
Implementation sequence
Common Sabre integration patterns
Pattern 1: Orchestrate travel booking
When to use this pattern
Use this pattern when a customer-facing or agent application needs one controlled process for shopping, selecting, booking, and confirming air, hotel, or car travel. It centralizes Sabre calls and prevents each channel from implementing separate authentication and booking safeguards.
Integration direction
Example Mapping
| Sabre Field | Canonical Field | Target Field |
|---|---|---|
| Offer.Price.Total | totalPrice | bookingRequest.totalPrice |
| FlightSegment.DepartureAirport | originAirport | itinerary.origin |
| FlightSegment.ArrivalAirport | destinationAirport | itinerary.destination |
| PNR.Locator | reservationLocator | bookingConfirmation.locator |
Martini implementation pattern
A Martini API receives the normalized booking request, and a workflow authenticates with Sabre, calls the required shopping or booking operations, applies fare and policy rules, and returns a canonical confirmation. The workflow persists correlation data before retrying uncertain booking or ticketing outcomes, checks for an existing PNR or confirmation, and routes reconciliation cases for review.
Martini capabilities used
- APIs
- workflows
- API consumption
- data mapping
- business rules
- secure configuration
- error handling
Pattern 2: Synchronize PNRs and itineraries
When to use this pattern
Use this pattern to make recently created or modified PNR and itinerary information available to CRM, traveler, expense, or customer-service applications. The exact retrieval and filtering method must follow the Sabre product and account capabilities rather than assuming a universal change feed.
Integration direction
Example Mapping
| Sabre Field | Canonical Field | Target Field |
|---|---|---|
| PNR.Locator | reservationId | Salesforce booking locator |
| Passenger.Name | travelerName | Salesforce contact name |
| FlightSegment.DepartureDateTime | departureLocalDateTime | Salesforce itinerary departure |
| HotelReservation.ConfirmationNumber | hotelConfirmation | Salesforce reservation reference |
Martini implementation pattern
A scheduled Martini workflow retrieves the supported Sabre search window, persists a checkpoint, transforms PNR and itinerary structures, filters sensitive fields, and upserts downstream records using stable locators and confirmation numbers. Bounded retries handle transport failures, while reconciliation handles incomplete or uncertain updates.
Martini capabilities used
- scheduled workflows
- API consumption
- checkpoint management
- data mapping
- validation
- idempotency
- monitoring
Pattern 3: Normalize air shopping and fares
When to use this pattern
Use this pattern when several booking channels need a consistent representation of Sabre offers, flight segments, branded fares, baggage, taxes, and pricing. It keeps Sabre-specific response structures behind a reusable internal API.
Integration direction
Example Mapping
| Sabre Field | Canonical Field | Target Field |
|---|---|---|
| Offer.OfferID | offerId | normalizedOffer.id |
| Offer.Price.Total | totalAmount | normalizedOffer.price.total |
| Fare.BaggageAllowance | baggageAllowance | normalizedOffer.baggage |
| FlightSegment.MarketingCarrier | marketingCarrier | normalizedOffer.segments[].carrier |
Martini implementation pattern
Martini calls the Sabre shopping API from a workflow, validates required pricing and segment fields, converts nested offers into a versioned canonical model, and exposes the normalized response through a Martini REST API. Business rules can filter carriers, fares, or markets; malformed offers are rejected or quarantined without discarding the full shopping response.
Martini capabilities used
- REST APIs
- workflows
- data mapping
- JSON transformation
- validation
- business rules
- API exposure
Pattern 4: Coordinate post-booking operations
When to use this pattern
Use this pattern for ticketing follow-up, itinerary delivery, traveler notifications, and downstream updates after a reservation or booking operation. It is appropriate when Sabre does not provide a suitable callback and the initiating application or a schedule must drive the process.
Integration direction
Example Mapping
| Sabre Field | Canonical Field | Target Field |
|---|---|---|
| PNR.Locator | reservationLocator | travelerApp.bookingId |
| Ticket.DocumentNumber | ticketNumber | travelerApp.ticketReference |
| Itinerary.Segments | segments | travelerApp.itinerary |
| Reservation.Status | reservationStatus | travelerApp.status |
Martini implementation pattern
A Martini workflow is triggered by the booking application or a scheduled retrieval, obtains current Sabre reservation and ticketing details, applies status and privacy rules, and sends a normalized update to the traveler application. The workflow records delivery state, avoids duplicate notifications, and uses reconciliation when Sabre or the downstream system returns an uncertain result.
Martini capabilities used
- workflow triggers
- scheduled workflows
- API consumption
- transformation
- conditional routing
- error handling
- monitoring
Applications commonly integrated with Sabre
Sabre data can be coordinated with adjacent travel, customer, finance, and workforce applications. The exact scope depends on the Sabre products, commercial entitlements, and APIs enabled for the customer account.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize traveler profiles, corporate accounts, service cases, and booking or itinerary summaries for customer-service and account teams. | Sabre → Martini → Salesforce | Martini retrieves or receives applicable Sabre reservation data, maps PNR and passenger details to Salesforce objects, applies field-minimization rules, and records correlation identifiers for updates and reconciliation. |
| SAP Concur | Exchange travel reservations, itinerary details, traveler information, and selected expense-related data for corporate travel operations. | Sabre → Martini → SAP Concur | A Martini workflow retrieves Sabre itinerary and reservation information, normalizes travel dates and segments, validates traveler and cost-center references, and sends approved data to SAP Concur with retry and duplicate safeguards. |
| Oracle Hospitality OPERA Cloud | Coordinate hotel content, reservations, property information, and hotel operational data where the relevant Sabre and OPERA products support the required exchange. | Sabre → Martini → Oracle Hospitality OPERA Cloud | Martini transforms Sabre hotel offers or reservation details into the OPERA Cloud model, applies property and confirmation-number matching, and routes validation or booking failures for operational review. |
| Microsoft Dynamics 365 | Synchronize corporate travelers, accounts, service interactions, and itinerary information with customer and service teams. | Sabre → Martini → Microsoft Dynamics 365 | Martini consumes the applicable Sabre API, maps PNR, passenger, and itinerary data to Dynamics 365, applies privacy filtering, and uses stable locators and confirmation numbers to prevent duplicate updates. |
| Amadeus | Support multi-source travel distribution, content comparison, migration, or aggregation scenarios where both providers are part of a broader travel platform. | Sabre → Martini → Amadeus | Martini calls the required provider APIs, maps air, hotel, or car content into a common travel model, applies source-selection rules, and returns normalized results while preserving provider-specific identifiers. |
| Travelport | Combine or compare travel content and support multi-GDS booking architectures through an orchestration layer. | Sabre → Martini → Travelport | A Martini workflow invokes the selected Sabre and Travelport operations, normalizes offers and itinerary structures, applies deduplication and business rules, and handles provider-specific failures independently. |
| Workday | Synchronize employee, traveler, cost-center, and corporate travel-policy information with a Sabre-facing travel process. | Workday → Martini → Sabre | Martini retrieves approved employee and organizational data from Workday, validates travel-policy attributes, and uses the result to enrich or authorize Sabre-facing booking workflows. |
| Booking.com | Combine accommodation content or reservation information within a broader travel platform where the relevant commercial and API arrangements are available. | Booking.com → Martini → Sabre | Martini maps accommodation content or reservation data into a common hotel model, applies source and availability rules, and coordinates downstream travel workflows without assuming direct native interoperability. |
How to build a Sabre integration in Martini
Objective
Establish separate certification and production connections to Sabre and keep credentials, PCC values, endpoints, and product settings outside workflow logic.
Instructions in Martini
- Create protected configuration for Sabre client ID and client secret
- Store environment-specific endpoints and account or PCC values securely
- Configure the OAuth 2.0 client-credentials request
- Define separate certification and production settings
Objective
Select the trigger that matches the Sabre operation and the availability of product-specific notifications.
Instructions in Martini
- Use an API request for booking or application-led operations
- Use a scheduler for PNR or itinerary synchronization
- Use a Sabre callback only after confirming it is available for the selected product
- Define the checkpoint or correlation input for each run
Objective
Call the appropriate Sabre REST or SOAP operation and capture the response, identifiers, and product-specific pagination or continuation information.
Instructions in Martini
- Obtain or reuse a valid OAuth token for REST calls
- Invoke the selected Sabre endpoint or SOAP service
- Handle pagination, result windows, or continuation tokens according to that API
- Capture Sabre locators, transaction identifiers, and response metadata
Objective
Coordinate shopping, booking, retrieval, transformation, downstream writes, and reconciliation as an explicit Martini workflow.
Instructions in Martini
- Separate transport, authentication, and business-level outcomes
- Persist transaction state before operations that may have uncertain results
- Route successful, partial, and unresolved outcomes separately
- Use reusable logic for token handling and common Sabre response processing
Objective
Convert Sabre-specific air, hotel, car, passenger, PNR, and ticket structures into a versioned internal model.
Instructions in Martini
- Map nested Sabre payloads into canonical travel objects
- Preserve local travel dates, time zones, airport details, and provider identifiers
- Transform JSON or XML according to the selected service
- Minimize sensitive passenger and document fields
Objective
Enforce fare, policy, validation, privacy, duplicate, and reconciliation rules before writing data or repeating a transaction.
Instructions in Martini
- Validate required identifiers, prices, segments, and status values
- Apply booking or corporate travel-policy rules
- Check existing locators and confirmation numbers before retrying
- Quarantine malformed or incomplete responses for review
Common Sabre data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Offers and air shopping results | Represent flight availability, itineraries, branded fares, price offers, baggage, and related shopping information. | Booking applications, travel platforms, Salesforce, data warehouses | Martini calls the applicable shopping API, normalizes offers and fare details, applies selection rules, and exposes a controlled response or forwards approved results. |
| Passenger Name Records (PNRs) | Contain reservation locators, passenger, itinerary, contact, segment, and booking information. | SAP Concur, Salesforce, Microsoft Dynamics 365, traveler applications | Martini retrieves PNRs using the product-specific search or retrieval capability, maps them to a versioned itinerary model, and uses locators for idempotent updates. |
| Passengers | Identify travelers associated with a PNR or reservation, including contact and selected document information. | Customer platforms, workforce systems, traveler applications | Martini validates and minimizes passenger fields, applies privacy rules, and maps only required attributes to downstream systems. |
| Flight segments and itineraries | Describe origins, destinations, schedules, inventory, fares, and multi-segment travel plans. | Booking channels, traveler applications, expense platforms, customer-service systems | Martini preserves local travel dates and times, transforms nested segment structures, and validates required airport, carrier, and schedule fields. |
| Tickets and documents | Represent ticketing outcomes and electronic travel document information. | Traveler applications, customer-service platforms, finance and reconciliation systems | Martini stores identifiers and status safely, avoids logging sensitive content, and coordinates downstream delivery or reconciliation when the Sabre service exposes the required data. |
| Hotel reservations and property content | Provide hotel availability, rates, room offers, property details, and hotel booking information. | Oracle Hospitality OPERA Cloud, travel platforms, CRM systems | Martini maps property, room, rate, and confirmation data, applies matching rules, and routes booking or validation exceptions. |
Authentication and security considerations
OAuth and account permissions
Sabre REST APIs commonly use OAuth 2.0 client credentials with Sabre-issued client credentials, bearer tokens, environment-specific endpoints, and account or PCC permissions. Product entitlements determine which operations are available.
Credential protection
Store client secrets, tokens, PCC values, and environment settings in protected Martini configuration or secrets rather than workflow logic. Separate certification and production credentials and endpoints.
Travel data protection
- Minimize PNR, passenger, document, and payment-related data copied to logs and downstream systems.
- Restrict access to workflows and APIs by environment and role.
- Apply retention policies to raw Sabre responses and never log full tokens.
Operational considerations for Sabre integrations
Rate limits and retries
Sabre quotas and transaction limits vary by product and account. Handle throttling with bounded backoff, and do not blindly retry booking or ticketing after a timeout.
Pagination and checkpoints
Search and retrieval APIs may use different page, token, or result-window conventions. Persist the last successful synchronization boundary only according to the selected API's documented behavior.
Idempotency and reconciliation
Persist internal correlation identifiers, Sabre locators, ticket numbers, and confirmation numbers. Check for an existing outcome before repeating uncertain transactions.
Schema and time variability
Air, hotel, and car payloads contain optional fields and product-specific extensions. Preserve local travel dates and time zones, validate required fields, and map into a versioned internal model.
Testing and change management
Test certification and production differences, SOAP faults, OAuth renewal, throttling, partial responses, duplicate events, and schema changes before deployment.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond point-to-point calls
Martini coordinates Sabre APIs, internal applications, databases, and messaging within explicit workflows rather than scattering booking and synchronization logic across scripts.
Reusable integration assets
Token handling, mapping, validation, business rules, and reconciliation logic can be reused across air, hotel, car, PNR, and ticketing processes.
Controlled contracts
Martini can expose normalized APIs that shield consumers from Sabre-specific payloads, credentials, and service differences while preserving provider identifiers for support and reconciliation.
Operational reliability
- Apply structured error handling, bounded retries, checkpoints, and duplicate controls.
- Keep certification and production configuration separate.
- Use workflow logs and monitoring to investigate throttling, schema changes, and uncertain booking outcomes.
Frequently asked questions
Sabre can be integrated primarily through REST APIs for air shopping, booking, PNRs, ticketing, hotel, car, and related travel services. OAuth 2.0 client credentials is commonly used for REST authentication. SOAP and XML services remain relevant for selected legacy or specialized workflows. Martini can orchestrate these calls, transform Sabre payloads, expose normalized APIs, and synchronize approved data with downstream systems.
Yes. Martini can integrate with Sabre by consuming Sabre REST APIs, consuming applicable SOAP services, securely handling OAuth credentials, transforming travel payloads, and exposing APIs for internal applications. Product-specific callbacks or notifications can be used only where Sabre explicitly provides them for the relevant account and service.
No. A dedicated Sabre connector is not required. Martini can integrate using Sabre's confirmed native mechanisms, including REST APIs, applicable SOAP services, OAuth 2.0 authentication, and product-specific callbacks or asynchronous interfaces where available.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Sabre. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Sabre, cloud infrastructure, or other third-party systems based on subscriptions, usage, and deployment model.
REST APIs should normally be assessed first because they cover major air, booking, PNR, ticketing, hotel, and car workflows. SOAP may be required for legacy or specialized services. OAuth 2.0 client credentials is the common REST authentication approach. A universal GraphQL API was not confirmed, so GraphQL should not be assumed for Sabre.
A general Sabre webhook facility covering all reservation, ticketing, hotel, and air-shopping events was not confirmed. Some products or customer arrangements may provide callbacks, queues, or asynchronous notifications. These must be verified for the specific product and account; otherwise, scheduled retrieval or application-triggered workflows are appropriate.
Use the retrieval and filtering capabilities of the selected Sabre API, persist a synchronization checkpoint where supported, and use stable keys such as PNR locators, ticket numbers, and hotel confirmation numbers. Martini can map nested Sabre JSON or XML into a versioned canonical model. Booking and ticketing retries should first check whether the original transaction succeeded, then use reconciliation rather than blindly repeating it.
Yes. Martini can expose a controlled REST API that presents normalized shopping, booking, itinerary, or reservation operations to internal applications. A workflow can authenticate with Sabre, apply business and privacy rules, transform the vendor response, and return a stable internal contract without exposing Sabre credentials or product-specific payloads to every consumer.
Related Martini documentation
APIs
Data
Build a maintainable Sabre integration with Martini
Use Martini to connect Sabre travel APIs with booking, customer, workforce, and operational systems through secure workflows, reusable mappings, controlled APIs, and resilient synchronization processes.