Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.travelbase.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Travel Industry Foundations

Before diving into the code, it is essential to understand the mechanics of global flight distribution.
Flight booking systems connect airlines, inventory, and booking platforms. When a user searches:
  • Query: Systems query airline Global Distribution Systems (GDS) or New Distribution Capability (NDC) APIs.
  • Calculation: Prices are calculated in real-time based on fare classes.
  • Results: Results are returned as flight options.
An offer is a priced flight option returned after a search. It acts as a snapshot of a flight’s availability and cost at a specific moment.It includes:
  • Flight segments and routes
  • Total pricing (including taxes)
  • Passenger details & baggage rules
Offers are temporary and typically expire within 15–30 minutes.
Flight prices are dynamic and influenced by Yield Management algorithms. They depend on:
  • Real-time demand and historical trends.
  • Remaining seat availability in specific “fare buckets.”
  • Time remaining before departure.
  • Booking (PNR): This reserves the seat in the airline’s system. It generates a Record Locator but does not yet authorize the issuance of a travel document.
  • Ticketing: This is the financial settlement. Once the payment is verified, an e-ticket number is issued. A booking is not a guarantee of travel until it is ticketed.
Bookings usually fail due to Inventory Drift (someone else took the last seat while you were entering payment details) or Price Changes (the airline updated the fare during the session).

​
Travelbase Integration

How Travelbase models and simplifies these complex travel industry workflows.
We support standard Bearer token and API Key authentication.
# Example header
Authorization: Bearer <your_token>
You can manage your production and sandbox keys from the Travelbase Dashboard.
EnvironmentBase URLPurpose
Sandboxhttps://sandbox.travelbase.aiTesting and development
Livehttps://live.travelbase.aiProduction bookings
Orders move through several states. Your frontend should be built to handle these transitions:
  • PENDING: Initial state after order creation.
  • PROCESSING: Ticketing is in progress with the carrier.
  • TICKETED: Success! The e-ticket has been issued.
  • FAILED: The booking could not be completed (e.g., payment failure).
Idempotency ensures that if a network error occurs, retrying the request won’t result in two seats being booked or two credit card charges.Always include the Idempotency-Key header:
Idempotency-Key: uuid-string-12345
Because ticketing can take anywhere from seconds to minutes, we use webhooks to notify you of status changes.
  • order.ticketed: Triggered when the e-ticket is ready.
  • order.failed: Triggered if the carrier rejects the final issuance.
Note: Webhook delivery is at-least-once. Ensure your endpoint handles duplicate events.

​
Common Integration Mistakes

Avoid these pitfalls to ensure a smooth “Go-Live” process.
Always retry 5xx errors using the same idempotency key.This ensures that duplicate requests do not result in double bookings or inconsistent state in your system.
Offers are time-sensitive.Always check the expires_at timestamp before attempting to book. Using an expired offer will result in failed bookings or pricing mismatches.
Polling the API for updates is inefficient and unreliable.Webhooks are the source of truth for asynchronous events such as:
  • Order status updates
  • Ticket issuance
  • Failures and refunds
Rely on webhooks to keep your system in sync.
A 201 Created response only confirms that the request was accepted.It does not mean the ticket has been issued.Always track the order lifecycle:
  • PENDING
  • PROCESSING
  • TICKETED or FAILED
Use webhooks or status endpoints to confirm final state.
Need more help? Join our Slack community or contact support at support@travelbase.ai.