Happy new year! During the last weeks of 2023 we released several features that we want to share with you.

First of all, we've moved to releasenotes as you can see, so you can find our updates here in https://airgateway.releasenotes.io.

New Features

Blue Biz and Corporate Loyalty Program certification with AF and KL. Now you can use Corporate Loyalty Program with AF and KL.
Special PTCs for Marine Private fares with AY.
OfferIDs array is now ignored in OfferPrice because it's not needed anymore. This was needed when offers could be combined from client, now we do all possible combinations so you only need to select one to get the details.
Unification of coupon status codes.
Credit card validations have been removed. We completely rely on airlines when sending credit card information to them. We have removed some validations like mandatory fields (address, email, series code...). This is specially interesting for some types of cards like UATP.
Bundles for U2 in OfferPrice.
Check if one order is voidable or you should cancel + refund.

Blue Biz / Corporate Loyalty Program with AF and KL

You can use Bluebiz or Corporate codes in different ways and steps. You can test this in BookingPad directly, check our article about this here.

Blue Biz recognition at Shopping

You can send the Blue Biz code inside "corporateLoyaltyProgramCodes" field so all the offers you'll receive will specifically for your corporate and if you create an order it will be tied to that corporate already.

{
  "corporateLoyaltyProgramCodes": {
    "AF": "XXXXXXX"
  },
  "metadata": {
    "country": "DE",
    "currency": "EUR",
    "locale": "de_DE"
  },
  "originDestinations": [
    {
      "arrival": {
        "airportCode": "MAD",
        "time": ""
      },
      "departure": {
        "airportCode": "CDG",
        "date": "2023-12-04",
        "time": ""
      }
    },
    {
      "arrival": {
        "airportCode": "CDG",
        "time": ""
      },
      "departure": {
        "airportCode": "MAD",
        "date": "2023-12-23",
        "time": ""
      }
    }
  ],
  "passengers": [
    {
      "passengerType": "ADT",
      "travelerReference": "ADT0"
    }
  ],
  "preferences": {
    "cabin": [
      "7"
    ],
    "nonStop": false
  }
}

Blue Biz recognition at booking creation

You can search regularly but then add the Blue Biz code in OrderCreate request directly. You can use the field "loyaltyProgramAccount" here (it will be for the current airline, obviously).

{
  "corporateID": "XXXXXX", // Only needed if you're using our Traveler Profiles system
  "loyaltyProgramAccount": "XXXXXXXX",
  "passengers": [
    {
      "data": {
        "address": {
          "cityName": "",
          "countryCode": "",
          "label": "addressAtHome",
          "postalCode": "",
          "street": ""
        },
        "birthdate": "1992-11-30",
        "email": "test@test.com",
        "fqtvInfo": {
          "account": {
            "number": ""
          },
          "airlineID": ""
        },
        "gender": "Male",
        "name": "TEST",
        "phone": "+34666234234",
        "surname": "TEST",
        "title": "MR"
      },
      "passengerType": "ADT",
      "travelerReference": "PAX1"
    }
  ],
  "shoppingResponseID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}

Corporate Recognition with a Published fare

You can send corporate program account codes in OrderCreate too. You can use the same "loyaltyProgramAccount field like before, but instead of sending a Blue Biz code, just send a Corporate code.

{
  "corporateID": "XXXXXXXXXXXXXXXXXXXX", // Only needed if you're using our Traveler Profiles system
  "loyaltyProgramAccount": "XXXXXX",
  "passengers": [
    {
      "data": {
        "address": {
          "cityName": "",
          "countryCode": "",
          "label": "addressAtHome",
          "postalCode": "",
          "street": ""
        },
        "birthdate": "1992-11-30",
        "email": "test@test.com",
        "fqtvInfo": {
          "account": {
            "number": ""
          },
          "airlineID": ""
        },
        "gender": "Male",
        "name": "TEST",
        "phone": "+34666234234",
        "surname": "TEST",
        "title": "MR"
      },
      "passengerType": "ADT",
      "travelerReference": "PAX1"
    }
  ],
  "shoppingResponseID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
}

Marine Private fares with AY

Now you can use new "SEA" PTCs to ask for Marine Private fares. You need to include the given fare preference and qualifier. Please try it in BookingPad if you want to get fresh examples (you have an article about this here).

{
  "metadata": {
    "country": "DE",
    "currency": "EUR",
    "locale": "de_DE"
  },
  "originDestinations": [
    {
      "arrival": {
        "airportCode": "MAD",
        "time": ""
      },
      "departure": {
        "airportCode": "HEL",
        "date": "2024-03-06",
        "time": ""
      }
    }
  ],
  "passengers": [
    {
      "passengerType": "SEA",
      "travelerReference": "SEA0"
    }
  ],
  "preferences": {
    "cabin": [
      "7"
    ],
    "fareList": [
      {
        "Code": "758",
        "Definition": "M"
      }
    ],
    "nonStop": false
  },
  "qualifier": {
    "airline": "AY",
    "code": "AYMARINE",
    "type": "account_id"
  }
}

Unification of Coupon status codes

We've unified all coupon statuses to always use the PADIS codeset 4405.

700 - No active itinerary
701 - Notification
702 - Active
703 - Queue placement is inhibited
704 - Queue level notification
705 - Queue being printed
706 - Sub-queue present
707 - On hold
708 - Exchanged to FIM
709 - Passenger deleted
710 - Refund Taxes / Fees / Charges Only
A - Add
AC - Accrual
AL - Airport Control
ALL - Allocated
AVA - Available
B - Flown / Used
BD - Lifted / Boarded
C - Change
CK - Checked-in
CLO - Closed
D - Reprint
DB - Deboarded
DN - Denied boarding
E - Exchanged / Reissued
F - Critical free text
G - Non air segment
I - Original Issue (Open for Use)
IF - Information only
INU - In use
IO - Irregular operations
K - Confirmed, effective, working, firm, etc
LIM - Limitations on use
NAV - Not available
NC - Not checked in
NS - Infant, no seat
OF - Offloaded
OK - Confirmed
OLD - Replaced item
OPE - Open for use
P - Provisional, draft proposed subject to change, etc
PAV - Partial Availability - Specified sub-elements only
PE - Print Exchange
PR - Printed
PRF - Preferred
PRP - Proposed/Intended Allocation
R - Request
RD - Redemption
REP - Replacement
REV - Revised
RF - Refunded
RQ - Requested
S - Suspended
SA - Space Available
SB - Standby
SRV - Serviceable
T - Ticketed
UNS - Unserviceable
V - Void
WL - Waitlisted
X - Cancel
PRTX - Printed Interline
CTRL - Control
NOGO - NO-GO
UTL - Unable to Locate
PRFD - Partially Refunded

The only exception to this is AERTiCKET which return different codes depending on each of their airlines, so we just rely on the information they return.

Bundles for U2

We have included bundles as "other offers" inside OfferPrice responses. So you can get details for a given offer from AirShopping but see more alternatives for the same offer with bundles which include other information like baggage or seats. This information is included in the same node we use for other airlines like BA when they include upsellings in their OfferPrice

"otherOffers": [
    {
      "createdAt": 1704380647,
      "disclosures": [
        {
          "descriptions": [
            {
              "category": "BAGGAGE_CARRYON",
              "item": "BAGGAGE_CARRYON",
              "metadataToken": "",
              "originDestinationReference": "",
              "properties": [
                {
                  "UOM": "CM",
                  "type": "Length",
                  "value": "45"
                },
                {
                  "UOM": "CM",
                  "type": "Width",
                  "value": "36"
                },
                {
                  "UOM": "CM",
                  "type": "Height",
                  "value": "20"
                },
                {
                  "UOM": "CM",
                  "type": "Length",
                  "value": "56"
                },
                {
                  "UOM": "CM",
                  "type": "Width",
                  "value": "45"
                },
                {
                  "UOM": "CM",
                  "type": "Height",
                  "value": "25"
                }
              ],
              "text": "One small cabin bag (Maximum size 45 x 36 x 20 cm.Must fit under the seat in front of you.)\nOne large cabin bag (Maximum size 56 x 45 x 25 cm.)",
              "units": "1"
            },
            {
              "category": "BOARDING",
              "item": "HIGH_PRIORITY",
              "metadataToken": "",
              "originDestinationReference": "",
              "text": "Speedy Boarding (Be amongst the first to board, or board at your leisure.)",
              "units": ""
            },
            {
              "category": "SEAT",
              "item": "SEAT_RESERVATION",
              "metadataToken": "",
              "originDestinationReference": "",
              "text": "Free Up Front seat",
              "units": ""
            }
          ],
          "listKey": "PC2"
        }
      ],
...

Check if one order is voidable or you should cancel + refund.

Until now, you could try voiding an order whenever you prefer, but this could lead to problems sometimes.

Until know, you could call OrderReshopRefund to know how much you'd get in a refund, but you could call OrderCancel directly too. You need to include the type in OrderCancel payload:

{
  "id": "AGW-JHTE1543KJ",
  "type": "void"
}

In order to improve this, we included a flag in our allowedRequests section so you could check if an order was still allowed to void or not.

"allowedRequests": {
    "pending": {
      "OrderCancel": true,
      "OrderReprice": true,
      "OrderSplit": false,
      "SeatAvailability": true,
      "ServiceList": true,
      "TicketIssue": true
    },
    "started": {
      "OrderCancel": false,
      "OrderReshop": true,
      "OrderReshopRefund": false
    },
    "ticketed": {
      "AncillariesOnHold": true,
      "OrderCancel": true,
      "OrderCancelToVoucher": false,
      "OrderReshop": true,
      "OrderReshopRefund": true,
      "OrderReshopRouteChange": true,
      "OrderSplit": false,
      "OrderVoid": false,
      "SeatAvailability": true,
      "ServiceList": true
    }

The problem with this approach is that, sometimes, new rules were introduced and we didn't know so maybe we expected an order to be voideable but the airline ended up saying "this is not voideable anymore". This OrderVoid flag is now deprecated and you should stop using it.

Now we have improved OrderReshopRefund a little bit so we can give you more information about airline's allowance to void:

We've improved the workflow to know if you can void an order or you need to cancel and refund. Now, whenever you try to cancel or void an order, you should call OrderReshopRefund first. Now, on top of previous information that we already included (the expected amount you'd receive in an refund), you'll receive another node with the type of OrderCancel you should call.

{
  "trace": {
    "requestID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "sessionID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
  },
  "type": "void"
}

There are three different values you can receive here:

void
refund
unknown

Void and Refund are self-explanatory. If you receive an unknown it means that we can't know if it's in voiding period or not. This is only happening with IB, BA and LAand, in these cases, you can decide if you try to void or refund. For instance, we have solved this in BookingPad by showing both buttons in those cases so the agents can decide what to do.

API Partners support

Remember that you can always check our dev guides and swagger docs to get the most up to date docs using our API.