Passenger External IDs

Distribusion assigns every passenger in a connections/find response a generated identifier (for example pax-33-1). Because Distribusion might sort the passengers it returns, the order of passengers in the response does not necessarily match the order you sent them in. If you correlate the returned passengers back to your own records by position, you can end up matching the wrong passenger.

The optional external_id lets you attach your own identifier to each passenger in the request. Distribusion echoes that identifier back on the matching passenger in the response, giving you a stable anchor to map passengers back to your records — independent of order.

How it works

• Add an optional external_id (string) to any passenger object in the connections/find request.
• When supplied, the value is echoed back on the matching passenger as attributes.external_id in the response.
• The generated identifier remains the passenger's canonical id (pax-{age}-{index}, 1-based index). All other references in the response — a fare's passenger_ids and each services[].passenger_ids — continue to use that generated id, not your external_id.
• If you omit external_id, behaviour is unchanged. The field is fully backwards-compatible.

Request

Send external_id on each passenger you want to track on c/f. Each such passenger must be queried individually (pax: 1).

 
{
  "passengers": [
    { "external_id": "my-pax-A", "max_age": 33, "pax": 1 },
    { "external_id": "my-pax-B", "max_age": 11, "pax": 1 }
  ]
}

Response

Your value appears as passengers.attributes.external_id on the matching passenger resource in included. Fares and services keep referencing the generated id through their passenger_ids.

 
{
  "included": [
    {
      "type": "fares",
      "id": "fare-1",
      "attributes": {
        "passenger_ids": ["pax-33-1", "pax-11-2"],
        "services": [
          { "service_type_id": "seat", "passenger_ids": ["pax-33-1"] }
        ]
      }
    },
    { "type": "passengers", "id": "pax-33-1", "attributes": { "age": 33, "external_id": "my-pax-A" } },
    { "type": "passengers", "id": "pax-11-2", "attributes": { "age": 11, "external_id": "my-pax-B" } }
  ]
}

To map a fare or service back to your own passenger record: read the generated ids from the fare's passenger_ids (or a services[].passenger_ids), find the matching passenger in included, and read its attributes.external_id.

Validation rules

1. Unique per request. Each external_id must be unique within a single request. Two passengers carrying the same value are rejected with the error "Two passengers cannot have the same external_id".
2. One passenger per object. A passenger object that sets external_id must represent a single passenger (pax: 1). Setting external_id on an object with pax > 1 is rejected with the error "Please query each passenger individually when requesting with passengers[].external_id".
3. Mixed supply is allowed. Validation is per passenger. You may set external_id on some passengers and omit it on others in the same request. Passengers that omit it simply have no external_id attribute in the response.

Scope and limitations

• connections/find only.external_id is accepted and echoed on connections/find. It is not carried through to follow-up calls (connections/vacancy, connections/seats, seats/availability, reservations/create), which regenerate their own passenger identifiers. Tracked as a separate workstream.
• Not sent to carriers. The identifier stays within Distribusion; carriers never receive it. It exists purely to help you correlate the connections/findresponse back to your own data.