A Duffel Flight API integration connects live airline shopping and booking capabilities with the PHPTRAVELS platform. It allows a travel agency or online travel agency to move customers through a structured workflow covering flight search, offer selection, price confirmation, passenger information, payment, order creation, booking references, and supported ancillary services.
PHPTRAVELS already provides a dedicated Duffel module setup covering signup, API credentials, admin settings, and markup configuration.
This guide goes beyond those initial steps and explains how the complete booking workflow operates in a real travel business.
For the basic credential configuration process, visit the PHPTRAVELS Duffel API integration.
What Is Duffel Integration with PHPTRAVELS?
Duffel integration with PHPTRAVELS connects the customer-facing booking engine and agency back office with Duffel’s flight shopping and order APIs.
In practical terms, the connection can help an agency:
- Receive a customer’s flight search request.
- Retrieve matching airline offers.
- Display routes, prices, operating airlines, baggage details, and fare conditions.
- Validate the selected offer before checkout.
- Collect passenger and contact information.
- Add supported seats or extra baggage.
- Process the appropriate payment workflow.
- Create an airline order.
- Save the booking reference and available ticket documents.
- Manage supported changes, cancellations, and airline updates.
The exact functionality available to an agency depends on its Duffel account, commercial approval, selected airlines, payment setup, PHPTRAVELS module version, and the agreed integration scope.
How Does the Duffel Flight API Work?
Duffel’s flight booking model is based on offers and orders.
A flight search begins with an offer request. This request describes the journey, travel dates, passenger types, and optional filters such as cabin class. Duffel sends that request to relevant airline sources and returns offers that match the search criteria.
For a technical overview of searching for flights, selecting an offer, and creating a booking, review Duffel’s official Getting Started with Flights guide.
Each offer can contain:
- One or more journey slices.
- Individual flight segments.
- Marketing and operating airlines.
- Departure and arrival information.
- Passenger pricing.
- Taxes and total price.
- Fare conditions.
- Baggage information.
- Supported additional services.
- Payment requirements.
- An expiration timestamp.
An offer represents a specific itinerary available at a particular price. Offers remain bookable for a limited period and commonly expire within approximately 30 minutes, although the integration must always use the exact expires_at value returned by the API.
After a customer selects an offer, the platform provides the required passenger, service, and payment information to create an order with the airline.
Duffel Flight API Integration Workflow
A production integration involves more than adding an API key. The booking platform must coordinate customer actions, supplier responses, payments, booking records, and operational updates.
1. The Customer Searches for a Flight
The workflow starts on the PHPTRAVELS flight search form.
The customer enters information such as:
- Origin and destination.
- Departure and return dates.
- One-way, return, or multi-city journey.
- Number and type of passengers.
- Preferred cabin class.
- Direct-flight or airline preferences.
PHPTRAVELS validates the search input and converts it into the format required by the Duffel API.
For example, a return journey is normally represented by two slices:
- The outbound journey.
- The return journey.
Passenger types and ages must also be mapped correctly because airline prices, document requirements, and booking rules may differ for adults, children, and infants.
2. PHPTRAVELS Sends an Offer Request
PHPTRAVELS sends the normalized search information to Duffel as an offer request.
Duffel processes the request against the airline content available to the agency’s account. The returned offers can then be transformed into the consistent layout used by the PHPTRAVELS booking engine.
This connection allows travelers to compare suitable flight options without leaving the agency’s website.
A reliable integration should also handle:
- Searches that return no flights.
- Incomplete supplier responses.
- Slow airline responses.
- Invalid airport or date combinations.
- Unsupported routes.
- Expired sessions.
- Different currencies.
- One-way and multi-city itineraries.
For platforms that want to display offers as they become available, Duffel also documents batch offer requests. This approach allows results to be retrieved progressively instead of waiting for the entire response to finish.
3. Flight Offers Are Displayed to the Customer
PHPTRAVELS presents the returned offers through its branded flight booking interface.
The customer should be able to review important information before selecting a flight, including:
- Total price.
- Currency.
- Departure and arrival times.
- Flight duration.
- Number of stops.
- Operating airline.
- Cabin class.
- Included baggage.
- Change and cancellation conditions.
- Payment requirements.
- Offer expiration.
The operating carrier is particularly important when a flight is marketed by one airline but operated by another.
A good booking interface should not reduce every result to only the airline name and total price. Fare restrictions, baggage allowances, connection times, and operating-carrier information can directly affect the customer’s decision.
4. The Selected Offer Is Retrieved and Validated
When the customer selects a flight, the platform should retrieve the individual offer again before completing checkout.
This step helps the booking engine:
- Confirm that the offer has not expired.
- Retrieve the most current offer details.
- Load available ancillary services.
- Confirm the payment currency.
- Check current fare conditions.
- Calculate the correct final amount.
- Detect any price change before the customer pays.
Airline prices and availability can change between search and booking. The final amount shown to the customer should therefore be based on the latest valid offer and the intended payment method. Duffel’s pricing guidance also notes that the selected services and payment information used during pricing must match the information used when creating the order.
5. Passenger Information Is Collected
Once the price has been confirmed, PHPTRAVELS collects the passenger and contact details required by the airline.
Depending on the route and airline, this information may include:
- Given name.
- Family name.
- Date of birth.
- Gender where required.
- Email address.
- Phone number.
- Passport number.
- Passport expiration date.
- Nationality.
- Loyalty-program details.
- Special assistance information.
Passenger names should be validated carefully because correcting them after ticketing may be restricted, chargeable, or unavailable.
The integration should preserve the relationship between each passenger and their selected services, such as a seat or checked bag.
6. Seats, Bags, and Other Ancillaries Are Added
Ancillaries allow an agency to create a more complete checkout experience and potentially increase the value of each booking.
Depending on the airline and offer, customers may be able to select:
- Free or paid seats.
- Additional checked baggage.
- Other supported airline services.
Duffel provides seat-map data that can be used to build an interactive seat-selection interface. Its documentation currently describes seat selection as part of order creation, while the precise availability depends on the airline and itinerary.
Additional baggage may also be available on qualifying offers. Duffel’s extra-bag workflow starts with retrieving the available services for the selected offer and including the chosen service when creating the order.
The booking interface must not promise a seat or baggage option before confirming that the selected airline offer supports it.
7. Markups and the Final Selling Price Are Applied
PHPTRAVELS can provide the agency-facing controls needed to configure pricing rules and markups.
An agency may apply different commercial rules based on factors such as:
- Fixed amount per booking.
- Percentage of the flight price.
- Route or destination.
- Airline.
- Cabin class.
- B2B agent group.
- B2C customer.
- Ancillary service.
- Sales channel.
The supplier cost, agency markup, payment charge, tax treatment, and final customer price should be recorded separately for accounting and reconciliation.
Duffel permits travel sellers to apply markups to flights and supported ancillaries. However, the amount collected from the traveler must still cover the relevant offer, services, currency conversion, and payment costs associated with the chosen payment model.
8. Payment Is Processed
Payment architecture is one of the most important parts of a Duffel API integration.
The integration must define:
- Who collects money from the customer.
- Which payment gateway is used.
- Who acts as the merchant of record.
- How the airline booking is funded.
- When the customer payment is captured.
- What happens if payment succeeds but booking fails.
- What happens if booking succeeds but the customer-facing response times out.
- How refunds are reconciled.
Duffel documents card and cash-based payment models. Cash payments use a funded Duffel Balance, while card-based workflows can involve customer or agency cards depending on the commercial setup.
For supported customer-card workflows, Duffel provides card collection and 3D Secure functionality designed to keep sensitive card details away from the travel seller’s own servers.
PHPTRAVELS can connect the customer checkout experience with the chosen gateway and supplier-settlement process, but the exact structure should be confirmed before development or production activation.
9. The Airline Order Is Created
After validating the offer, passengers, selected services, and payment information, PHPTRAVELS sends the order request to Duffel.
Duffel supports two main order types:
Instant order:
The order is created and paid for during the same booking request.
Hold order:
The flight space is reserved first and payment is completed later, provided the selected offer supports deferred payment.
Duffel indicates hold eligibility through the offer’s payment requirements. A hold order must be paid before its payment_required_by deadline or the reserved space can be released.
Hold orders can be useful for:
- Corporate travel approval.
- Offline customer confirmation.
- Bank-transfer workflows.
- Agent-assisted bookings.
- Temporary fare reservation.
However, not every offer can be held. The interface should only present this option when the supplier response explicitly allows it.
10. Booking References and Ticket Documents Are Stored
After a successful order, the response may provide:
- Duffel order ID.
- Airline booking reference.
- Additional carrier booking references.
- Passenger records.
- Complete itinerary.
- Payment summary.
- Order status.
- Available actions.
- Ticket-related documents.
The airline booking reference is commonly called a PNR or record locator. Travelers can use it to check in or retrieve their booking through the airline’s website.
Duffel’s Orders API can also return multiple carrier booking references for itineraries involving codeshare or interline flights. This helps customers identify the correct reference for the operating airline.
Airlines may return accountable documents with an order. The most common example is an electronic ticket containing its own unique identifier.
PHPTRAVELS should store the supplier order ID, PNR, ticket information, customer payment reference, and internal booking number as separate fields.
11. The Customer Receives a Booking Confirmation
Once the booking has been confirmed, PHPTRAVELS can generate a branded confirmation page and transactional email.
The confirmation should contain:
- Agency booking number.
- Airline booking reference.
- Full passenger names.
- Complete itinerary.
- Operating airlines.
- Departure and arrival terminals where available.
- Baggage allowance.
- Selected seats and services.
- Fare conditions.
- Payment summary.
- Customer-support information.
- Important check-in instructions.
The booking should only be presented as confirmed after the platform has received and recorded a valid supplier response.
If the supplier returns an asynchronous or uncertain response, the booking should remain pending until its final status is known. Duffel specifically warns that a 202 Accepted order response should not simply be retried because doing so could create a duplicate booking.
12. Webhooks Keep the Booking Updated
A flight booking does not stop after the initial confirmation.
Airlines may later change:
- Flight number.
- Departure time.
- Arrival time.
- Aircraft.
- Operating carrier.
- Connection.
- Entire itinerary.
- Booking status.
Duffel webhooks can notify the connected platform when supported events occur, including order creation and airline schedule changes. PHPTRAVELS can then process the event, update its local booking record, and trigger the relevant customer or agent notification.
Webhook processing should include:
- Signature or authenticity validation where supported.
- Event logging.
- Duplicate-event protection.
- Mapping to the correct booking.
- Status synchronization.
- Customer-notification rules.
- Manual-review handling.
- Failure and retry monitoring.
Without proper webhook processing, the information shown in the agency’s back office may become different from the supplier’s current order status.
Post-Booking Operations
Travel agencies need more than successful booking creation. Their teams must also support customers after payment.
A complete workflow should consider:
Order Retrieval
Agents should be able to retrieve the latest supplier record using the Duffel order ID or airline booking reference.
Cancellations
Duffel’s cancellation workflow can return the expected refund information before the cancellation is confirmed. The agency should show the fare rules, penalties, refund amount, and final customer impact before taking action.
Flight Changes
Supported order changes may require selecting a new itinerary and paying an additional amount. In some cases, a change may produce a refund instead.
Airline-Initiated Changes
Schedule changes must be reviewed and communicated to the traveler. Some cases can be handled through the API, while others may require supplier or airline support.
Refund Reconciliation
The system should separately record:
- Supplier refund.
- Airline penalty.
- Agency service charge.
- Payment-gateway refund.
- Customer refund.
- Currency difference.
- Refund status.
Not every airline, fare, or order supports the same post-booking actions. PHPTRAVELS should display only the actions currently allowed for that particular order.
What Does PHPTRAVELS Add to the Duffel API?
Duffel supplies airline shopping and order functionality. PHPTRAVELS provides the wider travel-commerce environment needed to turn that connection into a customer-facing business.
Depending on the selected product and implementation scope, that environment can include:
- B2C flight booking website.
- B2B agent portal.
- Customer and agent accounts.
- Search and checkout interface.
- Admin management.
- Markup configuration.
- Multiple currencies.
- Payment-gateway connections.
- Booking records.
- Invoices and confirmations.
- Sales and operational reporting.
- Additional hotel, tour, car, and transfer modules.
PHPTRAVELS presents its flight platform as a complete booking environment with B2B and B2C portals, supplier integrations, payments, markup controls, admin tools, and reporting.
The relationship can therefore be understood as follows:
| Layer | Main Responsibility |
|---|---|
| Duffel | Airline search, offers, orders, airline responses, supported ancillaries, and post-booking API operations. |
| PHPTRAVELS | Customer interface, agent portal, markup rules, booking records, admin workflows, and business reporting. |
| Payment Provider | Customer payment authorization, capture, refund, and settlement reporting. |
| Travel Agency | Commercial agreements, customer support, pricing strategy, policies, and daily operations. |
Benefits of Duffel API Integration for Travel Agencies
Modern Offer-and-Order Workflow
Duffel follows the airline retailing model of offers and orders. IATA describes NDC as a data-exchange standard built around airline offer and order management.
This can help an OTA structure the customer journey around current airline products rather than relying only on older availability displays.
Branded Flight Sales
Customers can search and book through the agency’s own PHPTRAVELS-powered website instead of being redirected to an unrelated booking environment.
Ancillary Revenue Opportunities
When supported by the airline and offer, the agency may include paid seats, extra baggage, and other services in the booking flow.
Pricing and Markup Control
The agency can create pricing rules suited to B2C customers, B2B agents, routes, airlines, or sales channels.
Centralized Operations
Bookings can be connected with the wider PHPTRAVELS back office instead of being managed through separate customer spreadsheets and disconnected supplier records.
Expandable Travel Platform
The agency can combine flights with other travel products available through PHPTRAVELS, such as hotels, tours, cars, transfers, or activities.
Important Requirements Before Going Live
Before enabling live flight bookings, the agency and development team should confirm the following areas.
Commercial Access
A technical connector does not automatically provide unrestricted airline inventory. The agency must complete the required Duffel onboarding and obtain appropriate live access.
Airline and Route Coverage
Review the airlines, routes, countries, cabin classes, and ancillary features available to the agency’s account.
Do not assume that every airline supports every Duffel feature.
Currency and Settlement
Confirm:
- Supplier currency.
- Customer currency.
- Markup currency.
- Payment-gateway currency.
- Duffel Balance or card settlement.
- Foreign-exchange handling.
- Refund conversion rules.
Price Revalidation
The selected offer should be retrieved and validated before the order is created.
Offer Expiration
The interface must monitor expires_at and prevent customers from attempting to book an expired offer.
Duplicate-Booking Protection
Booking requests must be designed to prevent accidental duplicate orders when a supplier response is delayed or uncertain.
Logs and Monitoring
Record important request IDs, order IDs, status changes, supplier errors, and webhook events without exposing access tokens or sensitive passenger data.
Common Duffel API Integration Mistakes
Treating API-Key Setup as the Whole Integration
API credentials only establish access. A production booking system also requires pricing, passenger validation, payment coordination, order handling, confirmations, monitoring, and post-booking support.
Displaying Stale Prices
The integration should validate the selected offer before accepting the final booking decision.
Mixing Customer Payment with Supplier Settlement
The system must clearly separate the money collected from the traveler from the method used to pay for the airline order.
Assuming Every Airline Supports the Same Features
Hold orders, paid seats, baggage services, changes, and cancellations vary by airline and offer.
Retrying an Uncertain Order Without Checking Its Status
A blind retry can result in duplicate reservations or charges. The integration should follow the API’s response-handling guidance.
Ignoring Post-Booking Events
A booking can change after confirmation. Webhooks, schedule-change handling, cancellations, and customer communication must be part of the original integration plan.
Saving Only the PNR
The system should also save the Duffel order ID, ticket documents, payment references, passenger-service relationships, and status history.
Is Duffel the Right Flight API for Your Agency?
Duffel can be a strong option for a travel agency or OTA that wants a modern API-driven flight booking workflow.
Before selecting it, evaluate:
- Airline coverage for your target markets.
- NDC and other content required by your business.
- Available fare types.
- Baggage and seat support.
- Payment and settlement options.
- Hold-order availability.
- Change and cancellation capabilities.
- Commercial approval requirements.
- Customer-support responsibilities.
- Integration and operating costs.
An agency with established GDS contracts, negotiated private fares, or specialized ticketing requirements should compare Duffel with its existing distribution options before replacing them.
Duffel can also be used as one supplier within a broader PHPTRAVELS integration strategy rather than being the only flight-content source.
Explore the complete list of available connections on the PHPTRAVELS integrations.
FAQs
What is the Duffel Flight API?
Can Duffel integrate with PHPTRAVELS?
Is Duffel API setup the same as full integration?
Does a Duffel order include a PNR?
Does Duffel provide electronic tickets?
Can travel agencies add a markup to Duffel flights?
Can Duffel manage cancellations and flight changes?
Launch Duffel Flight Sales with PHPTRAVELS
A successful Duffel integration is not only a connection between two APIs. It is a complete commercial and operational workflow covering flight discovery, accurate pricing, customer payments, airline orders, ticket information, confirmations, and post-booking support.
PHPTRAVELS provides the booking-engine and management environment needed to turn Duffel airline content into a branded B2C or B2B travel platform.
Start by reviewing the Duffel API integration setup, explore the broader flight API integration solution, and evaluate the PHPTRAVELS travel API integration services.
Ready to plan your booking workflow?
View the PHPTRAVELS live demo or contact the PHPTRAVELS integration team to discuss your Duffel account, payment model, airline requirements, and launch scope.