Specifying custom IDs for passengers when creating an offer request is now deprecated

Historically, we’ve allowed you to optionally specify a custom ID for each passenger when creating an offer request. These custom IDs are then used throughout the API.

We recently marked this feature as deprecated, and we’ve now removed it from our documentation. If you’re currently specifying custom passenger IDs, this will continue to work, and you do not need to make any changes to your integration.

We plan to drop support for this feature in the API at some point in the future. Before we do, we’ll give you plenty of notice and will offer you support with the change (including a migration guide).

You can now book extra bags using the Duffel API 🧳

We've released support for ancillary bags in the Duffel API. For some offers we now return a list of available_services, like extra baggages, that can be booked along with the offer.

We are releasing this feature for British Airways and Vueling to start and will be adding support for more airlines in the future. If you are interested in a specific airline, please let us know at help@duffel.com.

To make the integration of this new feature as smooth as possible we've written a step by step guide on how it works. We've also updated our API documentation to reflect the API changes.

Vueling's 'Optima Fare', now available!

As part of our Vueling offering, we now return 'Optima Fare' results.

This means that when you issue searches and get back offers from Vueling, you should see a mix of Optima Fare and Basic Fare offers β€” fare_brand_name on the slies will be either Basic or Optima.

The great news is that Optima Fare offers include a 25kg checked baggage! 🧳 and there are no changes to your integration required to start getting these results.

To read more about Vueling fares, head over to this blog post on blog.vueling.com.

We've added fare brand support for Cathay Pacific, Iberia and Singapore Airlines

We now return fare_brand_names in offers from Cathay Pacific πŸ‡­πŸ‡°, Iberia πŸ‡ͺπŸ‡Έ and Singapore Airlines πŸ‡ΈπŸ‡¬.

To learn more about fare brands, check out our changelog entry from a few weeks ago here.

Aegean Airlines and Olympic Air offers now include baggage information

When you search and get back an offer from Aegean Airlines or Olympic Air πŸ‡¬πŸ‡·, we'll now include information about any checked baggage included with the offer.

Change `iata_code` type to `string` in Aircraft schema

In our Aircraft schema, we had our iata_code type set as an integer. The correct type should be string.

An example of an aircraft that wouldn't be able to be represented correctly with a type of integer would be the Airbus Beluga with an iata_code of ABB.

This would only impact people type checking against our schema.

Segments on offers and orders in the API are now more consistent

We want offers and orders in our API to be as consistent as possible.

On offers' segments, we have the following. attri departing_at, origin_terminal, arriving_at and destination_terminal attributes.

On orders' segments, we have departure_datetime, departure_terminal, arrival_datetime and arrival_terminal.

To make these more consistent, we've now added the departing_at, origin_terminal, arriving_at and destination_terminal attributes to orders' segments, and have marked the old names (departure_datetime, departure_terminal, arrival_datetime and arrival_terminal) as deprecated.

For now, if you've built your integration using the old attribute names, you can continue using them without any changes. Before we drop support for the old attributes, we'll give you plenty of warning, and will share a guide on upgrading your integration.

Slices and segments now have `id`s

Slices and segments didn't use to have ids, but now they do. These ids uniquely identify the slices/segments inside the parent offer or order (i.e. the same segment across different offers/orders will have a different id).

This is being done as preparation work to support baggage services (ancillary baggages) in the near future 🧳

We now return `documents` (for example e-tickets) with orders πŸ“

Many airlines return "accountable documents" when an order is created. The most common type of document is the e-ticket (electronic_ticket), which represents the fact that the passenger has paid and is entitled to fly on the flights they've booked.

We now return these documents in the API with a type and a unique_identifier. For now, we'll only return e-tickets, with the type electronic_ticket. In the future we may return other kinds of documents like electronic miscellaneous documents (EMDs).

See the Order Schema in our API documentation for more details.

You can now provide passport information when creating an order with seven more airlines πŸ›‚

When creating an order, you can now optionally provide passengers' passport information for the following airlines:

  • American Airlines πŸ‡ΊπŸ‡Έ
  • Aegean Airlines πŸ‡¬πŸ‡·
  • Austrian πŸ‡¦πŸ‡Ή
  • Brussels Airlines πŸ‡§πŸ‡ͺ
  • Lufthansa πŸ‡©πŸ‡ͺ
  • Olympic Air πŸ‡¬πŸ‡·
  • Swiss πŸ‡¨πŸ‡­

Previously, this feature was only supported for Cathay Pacific.

This will save your customers time when they're ready to check in, as they won't have to enter their passport details again.

You never need to hard-code this list of airlines into your integration - instead, just look at the allowed_passenger_identity_document_types attribute on the offer you are booking. That way, as we add passport support for more airlines, it'll start working immediately in your integration.