Live demo

Guide

What is API integration, explained for travel businesses

An API integration is a connection that lets two software systems exchange data and trigger actions without a person re-typing anything. This guide explains how it works, using one hotel booking that travels between a traveller, a booking platform, a supplier API and a payment gateway.

  • One request, one response
  • REST, XML, SOAP and webhooks
  • A booking traced across four systems
  • How integrations are tested

The definition

What is API integration, in plain language

API stands for application programming interface: the set of rules a system publishes so other software can talk to it. API integration is the work of connecting your platform to one of those interfaces so that data moves and actions happen automatically.

In travel, that platform is usually a booking system such as Travel booking software, and the interface belongs to a supplier, a payment gateway or a business tool. Our Travel API integration page explains how PHPTRAVELS delivers these connections, and the All integrations lists the suppliers already connected.

  • Exchange data

    Rates, availability, customer details and status updates move between systems in a structured format.

  • Automate actions

    Search, book, pay, cancel and reconcile happen as requests, not as steps someone repeats by hand.

  • Track outcomes

    Every call carries a reference, so a failed booking can be traced back to the request that caused it.

Request

POST /v1/hotels/availability HTTP/1.1Host: api.supplier.exampleAuthorization: Bearer sk_test_••••••••Content-Type: application/json{  "city": "DXB",  "check_in": "2026-11-12",  "check_out": "2026-11-14",  "guests": 2,  "currency": "USD"}

Response

HTTP/1.1 200 OKContent-Type: application/jsonX-Request-Id: req_7f3a91{  "hotel": "Palm Marina Hotel",  "room": "Deluxe, 2 adults",  "rate": { "amount": 438.00, "currency": "USD" },  "refundable": true,  "rate_key": "rk_19d2c7"}
Sample call to a fictional hotel supplier. Field names, endpoints and amounts differ from one supplier to another.

Anatomy of one API call

  1. 1

    Endpoint and method

    The address of the operation and the verb used on it: POST to availability means search for rooms.

  2. 2

    Authentication

    A key, token or signature proves who is calling. Suppliers issue separate credentials for sandbox and production.

  3. 3

    Payload

    The structured input: city, dates, guests and currency. The supplier's documentation defines every field.

  4. 4

    Status code

    A number that says how the call went: 200 is success, 4xx a problem with the request, 5xx a problem on the supplier's side.

  5. 5

    Request ID

    An identifier both sides keep. When support asks what happened to a booking, this is what they search for.

  6. 6

    Response body

    The answer in the supplier's format, which your platform maps into its own rooms, rates and policies.

One booking, four systems

What API integration does during a hotel booking

Follow one two-night stay from search to voucher. Every arrow is an API call; the traveller only sees the first and the last.

  1. 01TravellerBooking platformSearches hotels in Dubai, two nights, two guests
  2. 02Booking platformSupplier APIAvailability request with dates, guests and currency
  3. 03Supplier APIBooking platformRooms, rates, policies and a rate key
  4. 04Booking platformTravellerResults shown with your markup and currency applied
  5. 05Booking platformSupplier APIPrice recheck on the chosen rate key before payment
  6. 06Booking platformPayment gatewayPayment authorization for the total
  7. 07Payment gatewayBooking platformAuthorized, signed webhook received
  8. 08Booking platformSupplier APIBooking request with guest details
  9. 09Supplier APIBooking platformConfirmation number and cancellation terms
  10. 10Booking platformTravellerVoucher, invoice and booking reference

The platform in the middle is where API integration lives: it translates between the traveller's screen and each supplier's format, and it stores every reference.

The same sequence serves Flight booking software with a GDS, Tour operator software with an activity supplier and Payment gateway integration with any gateway; only the field names change.

Integration styles

REST, XML, SOAP, webhooks and GraphQL

Suppliers publish their interfaces in different styles. The style is decided by the supplier's documentation, not by preference, so a travel platform needs to speak all of them.

  • REST and JSON

    JSON
    Data format
    JSON documents
    Transport
    HTTP methods: GET, POST, PUT, DELETE
    Typical in travel
    Newer flight, hotel, activity and payment APIs
    Strength
    Compact payloads and wide developer tooling
    Watch out for
    Loosely specified; each supplier interprets REST differently

  • XML and SOAP

    XML
    Data format
    XML documents, often with a strict schema
    Transport
    HTTP POST with a SOAP envelope or plain XML
    Typical in travel
    GDS, bedbanks and established hotel and tour systems
    Strength
    Formal contracts, signatures and service definitions
    Watch out for
    Verbose messages and heavier parsing

  • Webhooks

    EVENT
    Data format
    JSON or XML, pushed by the other side
    Transport
    HTTP POST to a URL you register
    Typical in travel
    Payment results, booking status changes, ticketing updates
    Strength
    No polling; your platform is told when something happens
    Watch out for
    Signatures must be verified and repeats handled

  • GraphQL

    QUERY
    Data format
    JSON, shaped by the query you send
    Transport
    A single HTTP endpoint
    Typical in travel
    Some newer distribution platforms and internal APIs
    Strength
    Ask for exactly the fields you need
    Watch out for
    Supplier support in travel is still uncommon

API integration versus API development

API integration

Connects your product to an interface that already exists. The supplier owns the API; you build the client, the mapping and the rules around it.

API development

Creates an interface that other systems use to connect to your product, such as a B2B API your agents' tools can call. You own the contract and its versions.

Many travel projects need both: the platform integrates suppliers on one side and publishes its own API to agents and partners on the other.

Before and after

What changes when systems are integrated

The same five steps of a booking, done by hand against supplier portals and done through API integration.

Search

Without integrationManual

An agent opens each supplier portal and copies prices into a quote.

With API integrationAutomatic

One search fans out to every connected supplier and returns one list.

Price

Without integrationManual

Markup is added in a spreadsheet; the rate may have changed by the time the quote is sent.

With API integrationAutomatic

Markup, taxes and currency rules apply at response time; the rate is rechecked before payment.

Book

Without integrationManual

Guest details are re-typed into the supplier portal; typos become booking errors.

With API integrationAutomatic

Details are sent once, validated and stored with the supplier's confirmation.

Pay

Without integrationManual

Payment is collected separately and matched to the booking later.

With API integrationAutomatic

Authorization, capture and refund are tied to the booking reference.

Service

Without integrationManual

Cancellations and changes mean another login and another email.

With API integrationAutomatic

Changes and cancellations run through the same connection and update the record.

Where API integration appears in a travel platform

Vocabulary

Terms you will meet in API documentation

Twelve words that appear in almost every supplier's developer portal, defined the way they are used in travel.

  • API

    Application programming interface: the published rules for talking to a system.

  • Authentication

    Proving who is calling, with an API key, a bearer token, a signature or an approved IP address.

  • Certification

    A supplier's review of your integration before production credentials are issued.

  • Endpoint

    One address for one operation, such as search, book or cancel.

  • Idempotency

    Sending the same request twice produces one result, which prevents duplicate bookings and charges.

  • Mapping

    Translating the supplier's fields, codes and names into your platform's own data model.

  • Payload

    The data carried inside a request or response, usually JSON or XML.

  • Rate limit

    The number of calls a supplier allows per second or per day before it starts refusing them.

  • Request and response

    One call: your platform asks, the supplier answers, and both sides log it.

  • Sandbox

    A test environment with fake inventory and test cards where nothing is really booked or charged.

  • Status code

    The HTTP number that summarises the result: 200 success, 401 unauthorized, 429 rate limited, 500 supplier error.

  • Webhook

    A call in the other direction: the supplier or gateway notifies your platform when an event happens.

Testing and scoping

How a travel API integration is tested before it goes live

An integration is only finished when the unhappy paths behave. A test run against the supplier sandbox covers the cases below before certification and the switch to production credentials.

run integration tests

supplier sandbox, nine cases

  • OK: Authentication with valid and expired credentials
  • OK: Invalid request rejected with a readable error
  • OK: Supplier timeout handled without a hanging booking
  • OK: Rate limit respected and retried after the wait
  • OK: Price change caught at recheck and shown before payment
  • OK: Duplicate submission returns the first booking, not a second one
  • OK: Cancellation applied and fees calculated
  • OK: Refund issued against the original payment
  • OK: Booking, payment and supplier references reconcile

All cases passed, ready for certification

What scoping needs from you

  1. 1Supplier agreement, documentation and sandbox credentials
  2. 2Markets, currencies, products and user roles
  3. 3Search, booking, change, cancellation and refund scope
  4. 4Certification requirements and the production access process

Ready to connect a supplier

PHPTRAVELS integrates suppliers, gateways and business tools into a self-hosted platform delivered with its source code. See Pricing for the three one-time plans, or ask us about a specific API.

Request a demoTalk to us

Keep reading

Questions

API integration questions, answered

Short answers to the questions people ask before their first integration project.

Talk to sales

API integration is a connection that lets two software systems exchange data and trigger actions automatically. One system sends a structured request, the other returns a structured response, and both follow agreed rules for security and data.

In travel it connects a booking platform with flight, hotel, tour or car suppliers, payment gateways and business tools. It supports search, price validation, booking, cancellation, refunds and reconciliation without re-keying.

REST is an architectural style that usually exchanges JSON over HTTP. XML is a data format still common among GDS and bedbank suppliers, often wrapped in SOAP. The supplier's contract and documentation decide which one you use.

It depends on supplier access, the endpoints in scope, certification, mapping rules and booking edge cases. A reliable estimate follows a review of the documentation, the credentials and the workflows you need.

Test authentication, valid and invalid requests, timeouts, rate limits, price changes, duplicate submissions, cancellations, refunds and reconciliation. In production, every request should be traceable to a booking reference.

No. Integration connects your product to an existing API; development creates an interface that others connect to. Travel platforms often need both: suppliers integrated on one side and a B2B API published to partners on the other.

Keep exploring

More from the platform