Technical Integration

Authentication Setup

OAuth 2.0 Configuration

The CheckInHandler API requires OAuth 2.0 Bearer token authentication. Contact the API product approvers to obtain credentials:

• javier.temprano.fernandez@tui.be
• emre.oegretmen@tui.com
• gema.jimenezruiz@tui.nl

Step-by-Step

1. Request API access — Apply for access via the developer portal
2. Receive credentials — You will receive a client_id and client_secret
3. Obtain token — Exchange credentials for an access token using client credentials flow
4. Include token — Add the token in the Authorization: Bearer <token> header on every request

Integration Guide

1. Verify Connectivity

Test your credentials with the record locator endpoint:

curl -X GET "https://test.api.tui/flight/newskies/checkinhandler/recordlocator?bookingId=TEST01&lastName=Testpassenger" \
  -H "Authorization: Bearer <token>"

2. Check-in Flow

Typical integration flow:

1. Resolve record locator — GET /recordlocator to get the PNR from a TPRL
2. Check availability — GET /checkinavailability to validate credentials and determine product type
3. Route the passenger:
   • If productType == "Harmonised" → proceed with your in-app check-in flow
   • If productType == "Legacy" → redirect to deepLinkUrl
   • If productType == "Hybrid" → show legacy deep link for legacy segments, in-app for harmonised

3. Overview Endpoint (Extended)

For richer UI experiences, use GET /checkinoverview which provides:

• Per-segment check-in windows
• Document availability status (can boarding passes be generated?)
• Pending check-in status (has the passenger started but not completed?)
• Route document eligibility

Best Practices

Booking ID Format

The bookingId parameter accepts both:

• TPRL (Third Party Record Locator) — typically from external booking systems
• PNR (Passenger Name Record) — the 6-character NewSkies record locator

The service resolves TPRLs to PNRs internally.

Last Name Matching

The lastName parameter is case-insensitive but must match the booking exactly. For compound last names, include the full name as registered.

Time Windows

Check-in availability is determined by configurable per-carrier time windows:

• checkInOpensMinutesBeforeDeparture — typically 1440 (24 hours)
• checkInClosesMinutesBeforeDeparture — typically 120-180 minutes

Only future segments (not yet departed) are returned.

Error Handling

Environment Configuration

HTTP Headers

Request Headers

Response Headers

Troubleshooting

401 Unauthorized

• Verify your OAuth token is valid and not expired
• Ensure your client_id has been approved for the flight-checkinhandler API product

404 Booking Not Found

• Verify the booking ID exists in the system
• Ensure the last name matches the booking

500 Internal Server Error

• The backend service may have encountered an issue connecting to NewSkies middleware
• Retry with exponential backoff (max 3 retries)
• If persistent, contact the Skywalker team

Empty Segments

• Only future segments are returned
• If all flights have departed, the segments array will be empty