With Travelfusion Online Checkin API, customers are able to check in travellers on any booking, regardless of whether it was made through Travelfusion, or through the agent themselves. It applies to any flight in the entire world inventory. This guide is designed to give a quick-start to the users' integration with the TF Online Checkin API.

The key advantage of TF Online Checkin API is the automation of the check-in. The API offers a 'fire-and-forget' process, where the user may request automated check-in at any time before flight, and the API takes care of the rest. Additionally, functionality is offered to amend the check-in request, request check-in status at any time, and so on.

This guide is designed to give a quick-start to the users' integration with the TF Online Checkin API.

Summary of functionality

The supported functionality is summarised as follows.

Interrogate the API for airline online check-in support, advance availability and parameter requirements.
Initiate a check-in process for a booking by passing in a number of required parameters.
Update check-in parameters and / or traveller details.
Retrieve check-in status of the travellers and flight details.
De-queue an existing check-in request.
Retrieve the boarding passes for a particular check-in.

In addition to the above functionality, TF offers API users the option to integrate online check-in within their standard TF Search and Book API integration. This option applies only to customers where TF is their one and only flight booking channel. Please contact Travelfusion for more information.

Disclaimer

By submitting the required parameters or API (Advance Passenger Information) the user of the TF Online Checkin API confirms that they have the consent of the passenger(s) to save their details for the purposes of the automated check-in process.

General information and user guidelines

The basic online check-in API interaction flow requires two compulsory steps. Firstly, to request check-in availability as early as possible in the user's booking flow. And lastly, to send the main check-in request at the time of sale of the booking (e.g. at the end of the user's booking flow); this is important, as it is how the API knows the time and the fact that a check-in was sold by the user. For any other than the described usage that the API user may require, please contact Travelfusion.

For example, an end user searches for a flight and selects a result. Next to their selection, or the next step (flight details display), they are shown the option and cost to purchase automatic online check-in. If end user picks the option, the API user must send the availability request to confirm check-in availability. Then, when the end user successfully completes the booking, the API user must send the check-in request, immediately after receipt of successful booking response.

The API assumes a single check-in request relates to a flight booking with a unique PNR. A single TF check-in reference is generated which uniquely identifies the TF online check-in for that booking. The API automatically checks in all travellers requested for that booking (for all its legs / segments and directions). However, the check-in status of a TF online check-in is reported per traveller per flight direction (outbound / inbound).

The API constantly monitors airlines for changes in the check-in opening times / availability and changes or cancellations of the checked-in flights. If a flight cancellation is a result of the API user's action, then the API user is responsible for issuing a de-queue request. The up-to-date flight details will be shown in every check-in flight details response.

The basic error code and handling is similar to this in Search and Book API which is described in the Error Codes and Handling Guide. Any deviation from the general error handling guide will be described in the XML commands section.

XML commands

This section contains a more detailed explanation of the API XML commands, including XML examples.

CheckinAvailabilityPlane Request

Initiates a check for online check-in availability. The purpose of this request is to inform about

a) whether automated online check-in is offered or not,

b) provide check-in opening time window (before flight), and

c) list all required parameters needed for the CheckinPlane request.

It requires a TF airline code and the airport route. A list of TF airline codes may be obtained by using the GetAirlinesData XML command.

</Airline>

</Traveller>

</TravellerList>

</Criteria>

</CheckinAvailabilityPlane>

</CommandList>

The <AirportcodeRoute> should contain two IATA codes for a single flight, three codes for a return flight (also, open-jaw example: LHR-MAD-LGW). Users should explicitly specify the ages of the travellers. If ages are not known, it is recommended to use 30 for adults, 9 for children and 1 for infants.

CheckinAvailabilityPlane Response

The response contains <IsAvailable> element. If check-in is available, the response includes all advance availability, authentication and check-in parameters that would be required if the user wanted to initiate the actual check-in process.

</Airline>

<Category>default</Category>

<Direction>outbound</Direction>

<TimeUnit>MINUTES</TimeUnit>

</AdvanceAvailability>

<Category>seat_selected</Category>

<Direction>outbound</Direction>

<TimeUnit>MINUTES</TimeUnit>

</AdvanceAvailability>

</AdvanceAvailabilityList>

<Name>TRAVELLER_SURNAME</Name>

<DisplayText>Lead traveller surname</DisplayText>

</AuthOptionItem>

<Name>BOOKING_REFERENCE</Name>

<DisplayText>Booking reference</DisplayText>

</AuthOptionItem>

</AuthOptionItemList>

</AuthOption>

<Name>BOOKING_REFERENCE</Name>

<DisplayText>Booking reference</DisplayText>

</AuthOptionItem>

<Name>OUTWARD_ORIGIN</Name>

<DisplayText>Origin airport IATA code</DisplayText>

</AuthOptionItem>

<Name>OUTWARD_FLIGHT_DATE</Name>

<DisplayText>Outward flight date</DisplayText>

</AuthOptionItem>

</AuthOptionItemList>

</AuthOption>

<Name>CC_LAST_4_DIGIT</Name>

<DisplayText>Last 4 digits of the card used for the booking</DisplayText>

</AuthOptionItem>

<Name>BOOKING_REFERENCE</Name>

<DisplayText>Booking reference</DisplayText>

</AuthOptionItem>

</AuthOptionItemList>

</AuthOption>

<Name>TF_BOOKING_REFERENCE</Name>

<DisplayText>Travelfusion Booking reference</DisplayText>

</AuthOptionItem>

</AuthOptionItemList>

</AuthOption>

</AuthOptionList>

<Name>PASSPORT_NUMBER</Name>

<ParamType>checkin</ParamType>

<DisplayText>Passport number</DisplayText>

</ParameterOptionItem>

<Name>PASSPORT_EXPIRY_DATE</Name>

<ParamType>checkin</ParamType>

<DisplayText>Passport expiry date (dd/mm/yyyy)</DisplayText>

</ParameterOptionItem>

<Name>PASSPORT_COUNTRY_OF_ISSUE</Name>

<ParamType>checkin</ParamType>

<DisplayText>Passport country of issue (two-letter code, e.g. GB)</DisplayText>

</ParameterOptionItem>

<Name>INFO_ADDITIONAL</Name>

<DisplayText>Additional information</DisplayText>

<Value>Can not check in: Unaccompanied minors (UM); Passengers travelling with a baby; Persons with reduced mobility; Passengers suffering from blindness or mental disabilities; Passengers travelling with a pet.</Value>

</ParameterOptionItem>

</ParameterOptionItemList>

</ParameterOption>

<Name>PASSENGER_COUNTRY_OF_ORIGIN</Name>

<ParamType>checkin</ParamType>

<DisplayText>Country of birth (two-letter code, e.g. GB)</DisplayText>

</ParameterOptionItem>

<Name>PASSENGER_DATE_OF_BIRTH</Name>

<ParamType>checkin</ParamType>

<DisplayText>Date of birth (dd/mm/yyyy)</DisplayText>

</ParameterOptionItem>

<Name>PASSENGER_GENDER</Name>

<ParamType>checkin</ParamType>

<DisplayText>Gender (M/F)</DisplayText>

</ParameterOptionItem>

<Name>ID_CARD_NUMBER</Name>

<ParamType>checkin</ParamType>

<DisplayText>Identity card number</DisplayText>

</ParameterOptionItem>

<Name>ID_CARD_EXPIRY_DATE</Name>

<ParamType>checkin</ParamType>

<DisplayText>Identity card expiry date (dd/mm/yyyy)</DisplayText>

</ParameterOptionItem>

<Name>ID_CARD_COUNTRY_OF_ISSUE</Name>

<ParamType>checkin</ParamType>

<DisplayText>Identity card country of issue (two-letter code, e.g. GB)</DisplayText>

</ParameterOptionItem>

<Name>INFO_ADDITIONAL</Name>

<DisplayText>Additional information</DisplayText>

<Value>Can not check in: Unaccompanied minors (UM); Passengers travelling with a baby; Persons with reduced mobility; Passengers suffering from blindness or mental disabilities; Passengers travelling with a pet.</Value>

</ParameterOptionItem>

</ParameterOptionItemList>

</ParameterOption>

</ParameterOptionList>

<DisplayName>Disclaimer</DisplayName>

<InfoType>remark</InfoType>

<Info>By submitting the required parameters or API (Advance Passenger Information) the user of the TF Online Checkin API confirms that they have the consent of the passenger(s) to save their details for the purposes of the automated check-in process</Info>

</SupplierInfo>

<DisplayName>CheckIn Terms and Condtions</DisplayName>

<Info>https://wizzair.com/en-gb/information-and-services/booking-information/check-in-and-boarding</Info>

</SupplierInfo>

<DisplayName>Prohibited Items</DisplayName>

<Info>https://wizzair.com/docs/default-source/downloadable-documents/list-of-prohibited-articles-in-cabin-baggage.pdf</Info>

</SupplierInfo>

...

</SupplierInfoList>

</CheckinAvailabilityPlane>

</CommandList>

Airlines may have different advance availability times depending on various factors (e.g. outbound vs inbound flight, or whether customer has already selected a seat or not, etc.) These are described in the <AdvanceAvailabilityList> element, as per the above XML example.

The <ParameterOptionItemList> describes all possible check-in options. See further below for examples.

The <DisplayText> is designed to be passed directly to the end user, so that if any new types of data are required it will work automatically without the need for development on the API-customer side.

However if you do not wish to use TF's suggested display text, you should predefine your own text and ensure that when unrecognised fields are received, you detect this and build support for it as soon as possible.

Alternatively, you could request that TF return a specific DisplayText and we can configure it on our side.

The <SupplierInfoList> represents information, provided by the supplier, that may be displayed to the customer; more details on the SupplierInfoList element can be found here.

CheckinPlane Request

Instructs the API to queue an automated online check-in with the given parameters, as shown in the XML example below. This request must be sent at booking sale time; for a different use-case, please contact Travelfusion. It is recommended submitting the CheckinAvailabilityPlane request right before CheckinPlane, as a last moment confirmation the automated online check-in is available indeed. Also, after CheckinPlane response is successfully received with a reference, it is recommended the API user checks the status of the check-in (by using GetCheckinDetailsPlane request).

The user may re-submit this request at a later time, if they need to update check-in parameters. In this case, the <TFCheckinReference> of an existing check-in must be included. The <UserParameterList> and <AuthOption> are updated as one piece, so they always need to be complete. Whereas the <TravellerList> would update in an incremental or override way.

The <UserParameterList> contains a number of parameters the user of the API may input in order to customise various functionality of the check-in. It should include the email where the boarding pass(es) will be emailed to (NOTE: the airline may not support an email address for checkin and may use the email address submitted at booking time). Other parameters like locale, phone numbers, email bcc, etc. may be used. More details can be found here. Please contact Travelfusion, if any additional parameters are required.

The <AuthOption> is mandatory; if it is not present, then the response will contain an <AuthOptionList> same as in the CheckinAvailabilityPlane response. Users must pick one of the options in the <AuthOptionList> and use it in this request.

The <TravellerList> is mandatory; if it is not present, then the response will contain an <ParameterOptionList> same as in the CheckinAvailabilityPlane response. Users must pick at least one of the options in the <ParameterOptionList> and use it inside every <Traveller> element. It is important the traveller <NamePartList> should follow the API guidelines about the general name format, especially when the first or last names consist of more than one parts; otherwise the API may erroneously error the check-in by connecting to the airline using wrongly formatted names.

A <ParameterOption> (per traveller) contains all the check-in parameters required. In case of a return flight, and if the traveller or agent requires to check in with different parameters (that are supported) per flight direction, then two <ParameterOption> elements must be specified; one with 'outbound' and another with 'inbound' values for <Direction>. In case of a single flight, the <Direction> can be omitted, or if present, it should have value of 'both'.

If the booking was made via Travelfusion, then it is recommended users include the <TFBookingReference> if available.

<Name>emailto</Name>

<Value>jimsmith@email.com</Value>

</UserParameter>

<Name>emailbcc</Name>

<Value>apiuser@email.com</Value>

</UserParameter>

<Name>locale</Name>

</UserParameter>

<Name>brand</Name>

<Value>FLYWITHUS</Value>

</UserParameter>

<Name>phone</Name>

</UserParameter>

</UserParameterList>

</Airline>

<Name>TRAVELLER_SURNAME</Name>

<Value>Smith</Value>

</AuthOptionItem>

<Name>BOOKING_REFERENCE</Name>

<Value>ABCDEF</Value>

</AuthOptionItem>

</AuthOptionItemList>

</AuthOption>

<Name>

<NamePart>Smith</NamePart>

</NamePartList>

</Name>

<Direction>outbound</Direction>

<Name>PASSPORT_NUMBER</Name>

</ParameterOptionItem>

<Name>PASSPORT_EXPIRY_DATE</Name>

</ParameterOptionItem>

<Name>PASSPORT_COUNTRY_OF_ISSUE</Name>

</ParameterOptionItem>

</ParameterOptionItemList>

</ParameterOption>

</Traveller>

</TravellerList>

</CheckinPlane>

</CommandList>

CheckinPlane Response

It contains a <TFCheckinReference> that identifies this check-in request.

<DisplayName>Disclaimer</DisplayName>

<InfoType>remark</InfoType>

<Info>By submitting the required parameters or API...</Info>

</SupplierInfo>

...

</SupplierInfoList>

</CheckCheckinPlane>

</CommandList>

GetCheckinDetailsPlane Request

Use this to check the current status of a check-in and flight details, given the <TFCheckinReference>.

</GetCheckinDetailsPlane>

</CommandList>

GetCheckinDetailsPlane Response

The response contains the status of the check-in per traveller per flight direction. It also contains the flight details. The <OutboundStatus> and <InboundStatus> elements contain one of the following values:

IN_PROGRESS - The check-in has been initiated. In case of return flights, the <InboundStatus> will remain in this status until inbound check-in has opened.

ERROR - There was an error that prevented the check-in. This would be an error that needs to be dealt with by the API user. A notification email is sent to the recipients specified in the user parameters of the check-in request. The status will contain attributes ecode, etext, edetail and edate that explain the problem, e.g. a traveller was missing from the list or had a wrong name.

COMPLETE - Traveller is successfully checked in.

UNCONFIRMED - The check-in may or may not have been made. Travelfusion cannot yet confirm the status of the check-in. The API will eventually change this to a different status. Meanwhile, the GetCheckinDetailsPlane request may be submitted, indefinitely, at a reduced frequency (every hour). The API user should contact Travelfusion if a check-in remains Unconfirmed for an extended period of time.

DEQUEUED - The check-in was requested by the API user to be dequeued.

ABORT_FAILED - This is assigned to check-ins that are still in an non-final status few hours before flight time. An notification email would be sent to the recipients specified in the user parameters of the check-in request.

</Airline>

<Name>

<NamePart>Peterson</NamePart>

</NamePartList>

</Name>

<OutboundStatus>IN_PROGRESS</OutboundStatus>

<InboundStatus>IN_PROGRESS</InboundStatus>

</CheckedIn>

</Traveller>

</TravellerList>

<SegmentOut>FR 1234|LTN|MAD|10/12/2016-14:45|10/11/2016-14:45|LTNDEP_1</SegmentOut>

<SegmentOut>FR 5678|MAD|BUD|10/12/2016-19:15|10/11/2016-14:45|Terminal 2B</SegmentOut>

</SegmentOutList>

<SegmentRet>FR 4321|BUD|MAD|17/12/2016-13:45|17/11/2016-13:45|Terminal 1A</SegmentRet>

</SegmentRetList>

</FlightDetails>

</FlightDetailsAudit>

</FlightDetailsAuditList>

<DisplayName>Disclaimer</DisplayName>

<InfoType>remark</InfoType>

<Info>By submitting the required parameters or API...</Info>

</SupplierInfo>

...

</SupplierInfoList>

</GetCheckinDetailsPlane>

</CommandList>

CheckinDequeuePlane Request

Instructs the API to de-queue a check-in that was previously requested via the CheckinPlane command. The de-queueing can be successfully performed up until few hours before the flight time.

</CheckinDequeuePlane>

</CommandList>

CheckinDequeuePlane Response

The response contains <TravellerList> element with check-in status per traveller at the time of de-queueing.

</Airline>

<Name>

<NamePart>Peterson</NamePart>

</NamePartList>

</Name>

<OutboundStatus>IN_PROGRESS<OutboundStatus>

<InboundStatus>IN_PROGRESS<InboundStatus>

</CheckedIn>

</Traveller>

</TravellerList>

</CheckinDequeuePlane>

</CommandList>

GetCheckinBoardingPass Request

This request is used to download the current boarding passes. If <Method> is 'email', then this will only result in re-sending the confirmation emails; the response will not contain any boarding pass data. If <Method> is 'inline', the response will contain the hex-encoded data of all boarding passes for the given check-in reference. This request should be the result of an end user action, and it is not supposed to be used automatically for every single check-in.

<Method>inline</Method>

</GetCheckinBoardingPass>

</CommandList>

GetCheckinBoardingPass Response

The response contains a list of boarding pass attachments.

<Type>application/pdf</Type>

</BoardingPass>

...

</BoardingPass>

...

</BoardingPassList>

</GetCheckinBoardingPass>

</CommandList>

CheckinStaticInfo Request

This request must be submitted at most once per day, at off-peak times (23:00 - 06:00 GMT). Please discuss with Travelfusion if you need to submit it more often. This request is used to retrieve all possible values that may appear in various XML elements in the responses of this API.

</CheckinStaticInfo>

</CommandList>

CheckinStaticInfo Response

<Categories> contains a pipe separate list of all possible values in <Category> element in CheckinAvailabilityPlane XML response.

<Directions> contains a pipe separated list of all possible values in <Direction> elements.

<UserParameters> contains a pipe separated list of all possible <UserParameter> names accepted in CheckinPlane XML request.

<AuthOptionItemList> all possible <AuthOptionItem> elements the API may require.

<ParameterOptionItemList> all possible <ParameterOptionItem> elements the API may require.

<Categories>default|seat_selected|infant</Categories>

<Directions>outbound|inbound|both</Directions>

</AdvanceAvailability>

<UserParameters>emailto|emailbcc|brand|locale|phone</UserParameters>

<Name>TRAVELLER_FIRST_NAME</Name>

<DisplayText>Lead traveller first name</DisplayText>

</AuthOptionItem>

<Name>TRAVELLER_SURNAME</Name>

<DisplayText>Lead traveller surname</DisplayText>

</AuthOptionItem>

...

</AuthOptionItemList>

<Name>PASSPORT_NUMBER</Name>

<ParamType>checkin</ParamType>

<DisplayText>Passport number</DisplayText>

</ParameterOptionItem>

<Name>PASSPORT_EXPIRY_DATE</Name>

<ParamType>checkin</ParamType>

<DisplayText>Passport expiry date (dd/mm/yyyy)</DisplayText>

</ParameterOptionItem>

...

</ParameterOptionItemList>

</CheckinStaticInfo>

</CommandList>

Test Online Check-in using <FakeCheckin>

The fake-check-in test allows users to test the TF Online Checkin API without having to connect to the airlines.

Simple FakeCheckin example

Request

</FakeCheckin>

<Name>emailto</Name>

<Value>name@email.com</Value>

</UserParameter>

</UserParameterList>

</Airline>

<Name>TRAVELLER_SURNAME</Name>

<Value>Smith</Value>

</AuthOptionItem>

<Name>BOOKING_REFERENCE</Name>

</AuthOptionItem>

</AuthOptionItemList>

</AuthOption>

</CheckinPlane>

</CommandList>

Response

The response will result in a successful complete check-in, using random (but airline valid) data for the flight / check-in times and traveller information.

Enhanced FakeCheckin example

This example shows how a user can change the parameters of the test fake-check-in. The required error codes (if needed) can be found in the response of the GetErrorCodes API specification.

Request

<Direction>outbound</Direction>

<Status>COMPLETE</Status>

</FakeCheckinStatus>

<Direction>inbound</Direction>

<Status>ERROR</Status>

</ErrorCode>

</FakeCheckinStatus>

</FakeCheckinStatusList>

<Direction>outbound</Direction>

<TimeUnit>MINUTES</TimeUnit>

</AdvanceAvailability>

<Direction>inbound</Direction>

<TimeUnit>MINUTES</TimeUnit>

</AdvanceAvailability>

</AdvanceAvailabilityList>

</FakeCheckin>

<Name>emailto</Name>

<Value>name@email.com</Value>

</UserParameter>

</UserParameterList>

</Airline>

<Name>TRAVELLER_SURNAME</Name>

<Value>Smith</Value>

</AuthOptionItem>

<Name>BOOKING_REFERENCE</Name>

</AuthOptionItem>

</AuthOptionItemList>

</AuthOption>

<Name>

<NamePart>Smith</NamePart>

</NamePartList>

</Name>

<Name>PASSPORT_NUMBER</Name>

</ParameterOptionItem>

<Name>PAX_DATE_OF_BIRTH</Name>

</ParameterOptionItem>

</ParameterOptionItemList>

</ParameterOption>

<Direction>outbound</Direction>

<Status>COMPLETE</Status>

</FakeCheckinStatus>

<Direction>inbound</Direction>

<Status>ERROR</Status>

</ErrorCode>

</FakeCheckinStatus>

</FakeCheckinStatusList>

</Traveller>

</TravellerList>

</CheckinPlane>

</CommandList>

Subpages (2): TF Online Checkin API Specification UserParameterList and Boarding Pass email sender