Contacts

A booking carries two kinds of contact data, and both APIs express them explicitly — nothing is inferred from ordering, and requests that are ambiguous are rejected rather than guessed at.

What goes where

Data	Where to send it	Notes
Booking email / phone / postal (the primary contact)	JSON: the contact field. XML: one unreferenced, untagged ContactInfo (or tag it <ContactPurposeText>Primary</ContactPurposeText>).	Required on create, and an email address is mandatory on it. On responses this is contacts[].contactTypeCode: "P".
Passenger irregular-ops email / phone (CTCE / CTCM)	JSON passengers[].contact. XML: ContactInfo referenced from that Pax via ContactInfoRefID.	Email and/or phone only — postal on a passenger contact is ignored.
Cardholder billing address	Payment payer, not contacts.	Different purpose from booking notification contacts.
Emergency contact / relationship	Not supported.	RelationshipToPax is rejected.

The booking contact

Every booking has exactly one primary contact, and it is the only booking-level contact a request can set or update. Order responses list booking contacts as contacts[] with a contactTypeCode and display name; entries other than "P" (Primary) may appear there when the airline manages additional contacts on the booking, but they are read-only through this API — a request targeting any other contact type is rejected.

Rules, enforced with a 400/422 rather than silently corrected:

• The primary is never guessed. On XML, with several ContactInfo entries, exactly one must be the primary: untagged and referenced by no Pax, or tagged <ContactPurposeText>Primary</ContactPurposeText> (matched case-insensitively; the tag works even on a Pax-referenced entry). More than one candidate is rejected. When nothing qualifies — every ContactInfo is untagged and referenced by a Pax — the lead passenger's contact becomes the primary, so the classic shared-contact shape still works.
• A contact-person name (name.givenName + name.surname; XML Individual > GivenName/Surname) is optional on the primary — it defaults to the lead passenger's name.
• Any other ContactPurposeText or contact type is rejected with the accepted values — including the legacy NTF tag from the retired documentation; tag the notification contact Primary instead, or leave it untagged.

Per-passenger contacts

Each passenger can carry their own contact (email and/or phone), stored against the passenger record for irregular-operations notification — the NDC equivalent of the legacy CTCE/CTCM SSRs mandated by IATA Resolution 830d.

• JSON: passengers[].contact on create, or an UpdatePassenger change with patch.contact.
• XML: a ContactInfo referenced from the Pax via ContactInfoRefID on create, or the same shape inside an UpdatePax.
• Read-back: JSON responses carry it inline as pax[].contact; XML responses emit a per-passenger ContactInfo entry referenced from the Pax.

Only email and phone are stored per passenger — postal data on a passenger-referenced contact is ignored, and a postal-only per-passenger contact is rejected on the JSON patch. A new per-passenger contact that merely restates the primary contact (the shape produced by echoing an order response back, or an XML Pax pointing at the primary ContactInfo) is recognized and skipped, so the same details are never stored twice; an existing per-passenger contact is always updated in place.

Lap infants have no passenger record of their own, so a per-passenger contact on an infant is rejected unless it simply restates the primary.

Examples

Primary + per-passenger (JSON)

{
  "passengers": [
    {
      "passengerId": "PX1",
      "type": "ADT",
      "name": { "givenName": "Jane", "surname": "Doe" },
      "contact": {
        "emailAddress": "[email protected]",
        "phoneNumber": "8015551212"
      }
    }
  ],
  "contact": {
    "emailAddress": "[email protected]",
    "phoneNumber": "8015559999"
  }
}

• contact → the booking primary.
• passengers[].contact → per-passenger irregular-ops email/phone (optional; separate from primary).

Primary + per-passenger (XML)

<ContactInfoList>
  <ContactInfo>
    <ContactInfoID>CT-PRIMARY</ContactInfoID>
    <EmailAddress>
      <EmailAddressText>[email protected]</EmailAddressText>
    </EmailAddress>
    <Phone>
      <PhoneNumber>8015559999</PhoneNumber>
    </Phone>
  </ContactInfo>
  <ContactInfo>
    <ContactInfoID>CT-PAX1</ContactInfoID>
    <EmailAddress>
      <EmailAddressText>[email protected]</EmailAddressText>
    </EmailAddress>
    <Phone>
      <PhoneNumber>8015551212</PhoneNumber>
    </Phone>
  </ContactInfo>
</ContactInfoList>
<PaxList>
  <Pax>
    <ContactInfoRefID>CT-PAX1</ContactInfoRefID>
    <Individual>
      <GivenName>Jane</GivenName>
      <Surname>Doe</Surname>
    </Individual>
    <PaxID>PX1</PaxID>
    <PTC>ADT</PTC>
  </Pax>
</PaxList>

• CT-PRIMARY is unreferenced and untagged → booking primary.
• CT-PAX1 is referenced from the Pax → per-passenger contact only.

Phone numbers and emails

• Phones must be convertible to E.164: send +-prefixed international numbers, 00-prefixed numbers, a national number with phoneCountryCode (XML CountryDialingCode), or a bare 10-digit US/Canada number (an 11-digit number starting with 1 also works). Anything else is rejected.
• Emails are format-checked on both surfaces; malformed addresses are rejected.
• On read-back, a number written to the booking by another channel is returned exactly as stored even when it is not valid E.164 — retrieval never fails over legacy contact data, so parse response phone numbers defensively.

Emergency contacts

Not supported. The reservation system has no storage for an emergency contact's name or relationship, so requests carrying RelationshipToPax are rejected outright instead of storing an incomplete record. Contact us if your integration requires emergency contact data.