Check In Process Flow

The check in process generally consists of:

  1. Retrieving a passenger from the system (to check that all necessary data is held for the passenger)
  2. Optionally assign a seat for the passenger
  3. Optionally add frequent flyer data for the passenger
  4. Optionally add Advanced Passenger Data (API) for the passenger
  5. Check the passenger in.

About Checkin Search Criteria

All of the /checkin APIs require the following parameters which are used to search the DCS for the correct passenger record:

  • departure date
  • flight number
  • departure airport
  • eTicket number
  • passenger first and last name

Obviously, it is not a good UX to make the user enter all these details on a mobile device. So, the preferred mechanism is to get the user to enter either a PNR Booking Reference or their Frequent Flyer Number. These values can be used to call the GET /reservations API or the GET /customerJourney API to retrieve the full PNR Booking data. The flight details and eTicket details can then be retrieve from the PNR data.

For airlines who do not use the SITA RES system (and therefore, the /reservations and /customerJourney APIs will not be available), it is necessary to get the user to enter all these values.

Mobile Boarding Pass

When checking in a passenger, you can specify that the boarding pass is to be distributed to mobile phone. In this case, additional rules are applied to the query to validate that the route is valid for mobile boarding. If the airline does not allow mobile boarding pass for a route, then you cannot check in a passenger with mobileBoardingPass=true for that flight.