Ellipse Gradient for Header

Travelport Integration Guide

Connect Travelport JSON REST APIs and Universal API SOAP services with enterprise booking, reservation, traveler, and finance workflows.

Travelport integration options at a glance

Travelport provides JSON APIs over REST for travel shopping, pricing, booking, ticketing, and servicing, while Travelport Universal API provides SOAP and XML services for existing implementations or capabilities not available through the JSON APIs. Travelport JSON APIs use OAuth-style bearer tokens, with account and environment provisioning determining available operations. General-purpose webhooks and bulk REST APIs were not confirmed, although selected products may expose asynchronous, queue-oriented, or callback capabilities. Martini can consume both API families, transform JSON and XML, expose normalized REST APIs, schedule synchronization workflows, and persist checkpoints and transaction state externally.

Integration pointSupported by Travelport?Common use casesHow Martini supports it
REST APIsYesTravelport JSON APIs support travel shopping, offer and fare validation, pricing, reservation creation, ticketing, servicing, and selected hotel, car, rail, or ancillary operations.Martini can consume Travelport REST APIs from workflows, map JSON requests and responses, orchestrate multi-step booking processes, and expose normalized REST endpoints.
SOAP APIsYesTravelport Universal API provides SOAP/XML services for search, booking, ticketing, and related operations, particularly for existing implementations or capabilities not available in JSON APIs.Martini can consume SOAP services, construct and parse XML, apply Travelport-specific headers and routing, and isolate Universal API details behind a stable internal API.
AuthenticationYesTravelport JSON APIs use OAuth-style bearer access tokens, while Universal API authentication and required headers vary by service and account configuration.Martini can store credentials and tokens as environment secrets, apply authorization headers, handle token expiration, and separate test and production configuration.
Bulk / async / batch APIsLimitedSome Universal API workflows include queue-oriented or asynchronous concepts, but a general-purpose bulk REST API for reservations, offers, or travelers was not confirmed.Martini can implement scheduled workflows, controlled concurrency, checkpointing, and idempotency around documented operations without treating queue behavior as universal webhooks.
Webhooks / outbound callbacksNot confirmedA general-purpose webhook framework for reservation, ticketing, or schedule-change events was not confirmed; product-specific callbacks must be verified.If a configured Travelport service provides a callback, Martini can expose a REST API or webhook-consuming workflow to receive and process it.
File / attachment APIsNot confirmedSome product-specific operations may provide travel documents or ticket-related outputs, but a general Travelport file or attachment API was not confirmed.Martini can process documented structured or binary responses when available, while routing unconfirmed document requirements for product-specific validation.
Database accessNoTravelport does not expose a customer-facing database connection as part of its standard integration APIs.Martini can use Travelport REST or SOAP services and persist selected reservations, offers, checkpoints, and audit data in an external SQL database.
SDKsNot confirmedTravelport provides API-oriented integration resources, but SDK availability and language coverage depend on the selected API family.Martini does not require a vendor SDK when required operations are available through REST or SOAP; custom logic can be added when needed.

How Travelport exposes data and business events

Travelport REST APIs

Travelport JSON APIs over REST are the preferred integration surface for new implementations where the required shopping, pricing, booking, ticketing, or servicing capability is available. Exact operations depend on the Travelport products and account provisioning.

Martini implementation pattern

Martini implementation pattern: Martini exposes or receives a booking-oriented API, calls the required Travelport JSON operations in sequence, maps responses into a canonical model, and returns a normalized result. The workflow can persist correlation identifiers and transaction state for reconciliation.

Implementation sequence

Receive a search or booking request through a Martini API or workflow trigger
Authenticate with Travelport using provisioned bearer-token credentials
Call the required shopping, pricing, reservation, or ticketing operation
Validate price, availability, identifiers, and required traveler data
Map the Travelport response to the internal or downstream contract
Persist transaction state and correlation identifiers

Travelport Universal API SOAP

Travelport Universal API provides SOAP/XML services for search, booking, ticketing, and related operations. It remains relevant for existing integrations and functionality not available through Travelport JSON APIs.

Martini implementation pattern

Martini implementation pattern: Martini exposes a stable internal REST contract, transforms JSON into Travelport-specific XML, sends SOAP requests with the required headers and agency context, parses the XML response, and shields downstream applications from Universal API details.

Implementation sequence

Receive a normalized request through a Martini REST API
Validate the required Travelport product, provider, branch, or account context
Transform the request into the required Universal API XML structure
Call the Travelport SOAP service with configured headers and credentials
Parse namespaces, errors, identifiers, and booking results
Return a normalized response and record the vendor correlation data

Travelport Queues and Async Workflows

Some Travelport Universal API workflows include queue-oriented or asynchronous concepts, but these should not be treated as a general-purpose webhook or bulk REST model. Supported queue behavior depends on the product and account configuration.

Martini implementation pattern

Martini implementation pattern: Where the specific Travelport service supports queue or asynchronous processing, Martini can schedule retrieval or processing, checkpoint progress, control concurrency, and reconcile uncertain results. If a product-specific callback is provided, Martini can expose an endpoint to receive it.

Implementation sequence

Confirm the enabled Travelport queue, callback, or polling behavior
Start the Martini workflow from a schedule or configured callback endpoint
Retrieve or receive the available Travelport status or result
Match the result to the stored transaction and correlation identifier
Apply idempotent updates to reservation or ticketing state
Escalate unresolved or inconsistent transactions for manual review

Common Travelport integration patterns

Pattern 1: Orchestrate travel search to booking

When to use this pattern

Use this pattern when a customer-facing booking application needs a controlled API for shopping, price validation, reservation creation, and ticketing. Search results are provisional, so the workflow should validate price and availability immediately before committing the booking.

Integration direction
Booking Application
Martini
Travelport
Example Mapping
Travelport FieldCanonical FieldTarget Field
Offer.IdentifierselectedOfferIdTravelport offer reference
Traveler.NametravelerNameTravelport traveler name
Itinerary.SegmentsjourneySegmentsTravelport itinerary segments
Price.TotaltotalAmountTravelport booking amount
Martini implementation pattern

Martini exposes a normalized REST API, calls Travelport search and pricing operations, applies fare and availability rules, then creates the reservation and performs configured ticketing or payment-related steps. It stores the reservation identifier and correlation data, distinguishes validation failures from transient errors, and reconciles timeouts before any retry of a financially significant operation.

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

Pattern 2: Mediate Universal API for legacy booking applications

When to use this pattern

Use this pattern when an existing application depends on Travelport Universal API or when a required capability is not available through the JSON APIs. The objective is to preserve a stable internal contract while isolating SOAP and XML details.

Integration direction
Internal Booking Application
Martini
Travelport Universal API
Example Mapping
Travelport FieldCanonical FieldTarget Field
bookingRequest.travelertravelerUniversal API traveler XML
bookingRequest.segmentsitinerarySegmentsUniversal API air or product segments
bookingRequest.paymentReferencepaymentReferenceUniversal API payment context
reservation.identifierreservationIdUniversal API reservation identifier
Martini implementation pattern

Martini receives JSON, validates required agency and provider context, transforms the request into Travelport XML, invokes the SOAP service, and maps the response into a normalized JSON contract. XML validation, namespace handling, SOAP error classification, and correlation logging are kept within the workflow so downstream applications remain independent of vendor-specific details.

Martini capabilities used
  • APIs
  • workflows
  • XML transformation
  • data mapping
  • validation
  • error handling

Pattern 3: Synchronize reservations and ticketing status

When to use this pattern

Use this pattern when internal systems need periodic updates for pending reservations, itineraries, ticketing results, or payment-related status and the configured Travelport product supports the required query or retrieval operation.

Integration direction
Travelport
Martini
NetSuite
Example Mapping
Travelport FieldCanonical FieldTarget Field
Reservation.IdentifierexternalReservationIdNetSuite external reference
Reservation.StatusbookingStatusNetSuite booking status
Itinerary.SegmentstravelSegmentsNetSuite itinerary data
Payment.StatuspaymentStatusNetSuite payment status
Martini implementation pattern

A scheduled Martini workflow retrieves eligible or recently changed Travelport data, processes continuation information where provided, maps records to NetSuite, and writes updates using stable external identifiers. Checkpoints, duplicate detection, controlled concurrency, and retry classification prevent missed updates and repeated financial postings.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination and checkpointing
  • data mapping
  • idempotency
  • monitoring

Pattern 4: Route Travelport exceptions to service operations

When to use this pattern

Use this pattern for booking failures, availability changes, schedule-related exceptions, uncertain transaction outcomes, or manual review cases that require operational ownership rather than automatic retry.

Integration direction
Travelport
Martini
ServiceNow
Example Mapping
Travelport FieldCanonical FieldTarget Field
Error.CodevendorErrorCodeServiceNow error code
Correlation.IdentifiertransactionCorrelationIdServiceNow correlation reference
Reservation.IdentifierreservationIdServiceNow booking reference
Error.MessagesanitizedErrorSummaryServiceNow case description
Martini implementation pattern

Martini classifies Travelport responses into retryable, user-correctable, configuration, and reconciliation categories. It creates a sanitized ServiceNow case for unresolved exceptions, includes vendor identifiers and workflow context, and prevents operators from accidentally submitting a duplicate booking while the original transaction is being investigated.

Martini capabilities used
  • workflows
  • business rules
  • data mapping
  • error handling
  • API exposure
  • auditability

Applications commonly integrated with Travelport

Travelport can be connected with named enterprise applications to coordinate booking requests, traveler information, reservation updates, ticketing status, financial reconciliation, and operational exceptions. Exact flows depend on the Travelport products and APIs provisioned for the customer.

Application Scenario Direction Martini Pattern
Salesforce Synchronize traveler profiles, corporate travel requests, reservation status, and customer service information. Salesforce → Martini → Travelport Martini receives booking or traveler requests from Salesforce, validates and maps them into Travelport REST or SOAP calls, then returns normalized reservation and itinerary updates to Salesforce. Correlation identifiers and recoverable errors are retained for reconciliation.
SAP Concur Connect corporate travel requests, traveler data, itinerary details, and booking or ticketing status. SAP Concur → Martini → Travelport A Martini workflow coordinates traveler and trip data between Concur and Travelport, transforms product-specific payloads, applies booking and status rules, and records transaction state before retrying or escalating uncertain operations.
Workday Synchronize employee and traveler information for managed corporate travel programs. Workday → Martini → Travelport Martini retrieves eligible worker or traveler information from Workday, maps it to the required Travelport context, and applies scheduled, incremental synchronization with validation and checkpoint persistence.
Oracle Cloud Applications Transfer travel-related customer, employee, payment, supplier, or financial reconciliation data around booking processes. Travelport → Martini → Oracle Cloud Applications Martini consumes reservation, payment, and ticketing results from Travelport, transforms them into Oracle Cloud Applications formats, routes business exceptions, and prevents duplicate financial updates using stable identifiers.
ServiceNow Create service cases for booking failures, schedule changes, refunds, and traveler support events. Travelport → Martini → ServiceNow Martini classifies Travelport errors or operational exceptions, creates ServiceNow cases with sanitized context, and can receive approved operational actions before invoking the relevant Travelport API.
NetSuite Transfer booking, ticketing, payment, invoice, and reconciliation data into finance and ERP processes. Travelport → Martini → NetSuite A scheduled or event-triggered Martini workflow retrieves completed booking and ticketing results, maps amounts and identifiers to NetSuite records, validates currency and status, and records reconciliation outcomes.
Jira Track booking-flow defects, integration failures, manual review tasks, and supplier exceptions. Martini → Jira Martini routes non-recoverable failures and unresolved booking states to Jira with correlation IDs, sanitized payload details, and workflow status so technical teams can manage remediation without resubmitting transactions blindly.

How to build a Travelport integration in Martini

Objective

Establish Travelport access for the selected JSON API or Universal API family and keep environment-specific credentials separate.

Instructions in Martini

  • Confirm the Travelport product, API family, environment, and account or branch context
  • Store OAuth client credentials, tokens, API credentials, and required headers in Martini Secrets Management
  • Configure separate test and production environments
  • Validate access with a non-destructive operation

Objective

Select the trigger that matches the business process, without assuming that Travelport provides general-purpose webhooks.

Instructions in Martini

  • Use a Martini REST API for synchronous search or booking requests
  • Use a schedule for supported reservation or ticket-status synchronization
  • Use a callback endpoint only when the specific Travelport product and account document that capability
  • Use a manual or operational trigger for reconciliation workflows

Objective

Call the required Travelport operations and manage multi-step travel transactions explicitly.

Instructions in Martini

  • Retrieve offers or reservation data through the documented Travelport REST or SOAP operation
  • Process continuation information or page parameters where provided
  • Capture Travelport identifiers, response status, and correlation data
  • Revalidate price and availability before a booking commit

Objective

Coordinate search, pricing, booking, payment-related, ticketing, servicing, and downstream operations as controlled workflow stages.

Instructions in Martini

  • Separate provisional shopping from financially significant booking or ticketing actions
  • Apply conditional routing based on product, status, and error category
  • Persist transaction state before and after significant operations
  • Use controlled concurrency for scheduled or queue-oriented processing

Objective

Convert Travelport JSON or XML structures into canonical models and application-specific contracts.

Instructions in Martini

  • Map Offer, Product, Reservation, Traveler, Itinerary, and Payment fields explicitly
  • Maintain separate mappings for Travelport JSON APIs and Universal API XML
  • Preserve vendor identifiers and required pricing, tax, currency, and restriction details
  • Redact sensitive traveler or payment data from diagnostic output

Objective

Apply validation, idempotency, reconciliation, and business rules before writing or retrying data.

Instructions in Martini

  • Validate required traveler, itinerary, provider, and account context
  • Detect duplicate bookings using internal transaction state and Travelport identifiers
  • Classify errors as retryable, user-correctable, configuration-related, or reconciliation cases
  • Do not blindly retry a booking or ticketing request after a timeout

Common Travelport data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
OfferA priced travel offer returned from shopping or search, such as an air itinerary or ancillary option.Booking applications, Salesforce, SAP Concur, and internal travel platformsMartini validates and maps offer details, preserves price and availability context, and passes a selected offer into pricing or booking workflows.
ProductA bookable travel product including air, hotel, car, rail, or ancillary products.Booking platforms, reservation systems, finance applications, and customer service systemsMartini normalizes product-specific attributes while retaining vendor identifiers, restrictions, supplier details, and product-level status.
ReservationA booking containing selected travel products and traveler information.Salesforce, SAP Concur, ServiceNow, NetSuite, and customer-facing applicationsMartini uses reservation identifiers for correlation, idempotency, status synchronization, reconciliation, and downstream updates.
TravelerA passenger or customer associated with a reservation, including identity and contact information.Workday, Salesforce, SAP Concur, and booking applicationsMartini validates, minimizes, and maps traveler data according to the target contract while limiting sensitive values in logs and persisted payloads.
ItineraryTravel segments and journey details associated with an offer or reservation.Customer portals, Salesforce, SAP Concur, ServiceNow, and finance systemsMartini transforms segment, date, location, fare, and status fields into canonical itinerary structures and updates targets idempotently.
PaymentPayment information or payment-related data used during booking and ticketing flows.NetSuite, Oracle Cloud Applications, reconciliation databases, and booking applicationsMartini applies payment-related business rules, minimizes sensitive data, preserves transaction references, and avoids exposing payment credentials in logs.

Authentication and security considerations

Authentication model

Travelport JSON APIs use OAuth-style bearer access tokens. Universal API authentication and required SOAP headers vary by service, account, and configuration.

Secrets and environments

  • Store client credentials, tokens, API credentials, and environment-specific values in Martini Secrets Management.
  • Separate test and production credentials and endpoints.
  • Confirm required PCC, branch, provider, agency, or account context before production use.
  • Handle token expiration and reauthentication explicitly.

Sensitive data

Traveler identity, contact, payment, and itinerary data may be sensitive. Apply least-privilege access, minimize persisted payloads, redact logs, and protect credentials and stored data according to applicable privacy and payment obligations.

Operational considerations for Travelport integrations

Provider limits and retries

Travelport quotas and commercial limits can vary by account, API, provider, and operation. Use controlled concurrency, respect throttling responses such as HTTP 429, and apply exponential backoff to transient failures. Do not blindly retry booking or ticketing after a timeout.

Pagination and checkpoints

Process continuation tokens or page parameters where provided, set explicit result limits, and persist checkpoints for scheduled synchronization. Do not assume a single response contains every result.

Idempotency and reconciliation

Use internal transaction state, correlation identifiers, reservation identifiers, and duplicate detection before creating bookings or posting financial updates. Resolve uncertain outcomes with a lookup or reconciliation workflow before resubmission.

Schema and testing

Travelport JSON and Universal API schemas can evolve independently. Isolate vendor mappings, validate required fields, test XML namespaces and SOAP headers, monitor version notices, and test price or availability changes between shopping and booking.

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

Orchestrate complete travel transactions

Martini coordinates multi-step flows such as search, price validation, booking, payment-related processing, ticketing, servicing, and downstream updates without forcing each application to implement Travelport-specific logic.

Separate vendor details from enterprise contracts

Martini can expose a stable REST API while consuming Travelport REST or SOAP services behind it. JSON and XML mappings, validation, business rules, and provider-specific headers remain centralized and reusable.

Operate integrations reliably

Workflows can classify errors, apply controlled retries, persist checkpoints, handle scheduled synchronization, and route uncertain booking outcomes for reconciliation. This is more maintainable than isolated scripts or tightly coupled point-to-point calls.

Support change and visibility

Reusable workflows and explicit mappings make it easier to evolve Travelport API families, add enterprise targets, monitor transactions, and protect sensitive traveler and payment information.

Frequently asked questions

How can Travelport be integrated with enterprise systems?

Travelport can be integrated through its JSON APIs over REST or through Travelport Universal API SOAP services. REST supports travel shopping, pricing, booking, ticketing, and servicing where provisioned; Universal API remains relevant for existing implementations and capabilities not available through JSON APIs. Martini can orchestrate these calls, transform JSON and XML, expose normalized APIs, and synchronize results with enterprise applications.

Can Martini integrate with Travelport?

Yes. Martini can integrate with Travelport by consuming Travelport JSON REST APIs and Universal API SOAP services, using configured authentication, workflows, mappings, validation, and error handling. Martini can also expose APIs for booking applications and support scheduled synchronization where the required Travelport operations are available.

Do I need a connector to integrate Travelport with Martini?

No. A dedicated Travelport connector is not required. Martini can use Travelport’s documented REST and SOAP APIs, with Martini handling authentication, orchestration, JSON or XML transformation, business rules, retries, and error processing.

Is there any extra Lonti cost to integrate Travelport with Martini?

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

Which Travelport integration methods should a new implementation use?

Travelport JSON APIs over REST should generally be evaluated first for new implementations when they provide the required shopping, pricing, booking, ticketing, or servicing capability. Travelport Universal API SOAP services remain relevant for existing integrations and functions available only through the SOAP/XML interface.

Does Travelport provide webhooks or booking events?

A general-purpose Travelport webhook framework covering all reservation, ticketing, and schedule-change events was not confirmed. Some products or enterprise workflows may provide queues, polling, asynchronous behavior, or callbacks, but these must be verified for the specific product and account. Martini can receive a documented callback through an exposed API.

How does Martini synchronize Travelport reservations and itineraries?

Martini can run scheduled workflows that retrieve supported reservation, itinerary, ticketing, or payment-related data, process continuation information where provided, and update target systems using stable identifiers. Checkpoints, duplicate detection, controlled concurrency, and reconciliation logic help manage incremental synchronization.

Can Martini expose an API façade for Travelport?

Yes. Martini can expose a normalized REST API for internal applications while handling Travelport REST or SOAP calls behind the interface. This can provide a stable contract, centralize authentication and business rules, and isolate downstream applications from Travelport-specific JSON structures, XML schemas, and service headers.

Related Martini documentation

APIs

Workflows

Security

Reliability

Connect Travelport with your enterprise systems

Use Martini to integrate Travelport REST and SOAP services with booking applications, traveler systems, finance platforms, and operational workflows through secure APIs, reusable workflows, and controlled data transformation.

EXPLORE MARTINI
BOOK A DEMO