# Flight data and bookings

> Connect Amadeus, FlightAware, Cirium, OAG, SITA or Sabre to LightHouse, read-only: what to paste, the fields to name, and which passenger data is left out by default.

The engine reads flight status, schedules, baggage and bookings from your data providers into a knowledge base, for operations, disruption, customer and ground agents.

Content is read in place, in your deployment, in your own account. LightHouse receives ids, hashes and counts only. Flight and passenger records are not transmitted, and LightHouse does not open the credential.

## Read-only, and what is left out

Aviation connectors never book, change, cancel or file anything, so **read and write is refused**: connect them as **Read**. Passenger personal data stays in your deployment. By default these are left out:

- travel document numbers;
- dates of birth;
- health and disability special service requests (MEDA, WCHR, BLND and the rest of the IATA health set).

## Connect in LightHouse

You need the **Client administrator** (`client_admin`) role, signed in as a person, and a deployment whose engine reads this connector ([compatibility reference](/concepts/telemetry-contract/#compatibility-reference)) and keeps credentials in your own store.

1. Get the key from the provider, as the section below describes.
2. Go to **Setup and admin → Connectors**, find the provider (search for it, or filter by **Aviation** or **Amadeus**), and choose **Connect**.
3. Name the fields listed, and leave the access level at **Read**.
4. Paste the key. Your browser seals it to your deployment; LightHouse never sees it.
5. Your deployment keeps it and checks it. The card shows the result.

## What the health codes mean

| Code            | The card says                                                            | What to do                                                               |
| --------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------ |
| `scope_missing` | The token signs in, but a scope it carries writes (the scopes are named) | Make a credential with read scopes only, and connect it again            |
| `auth_failed`   | The provider refused it                                                  | It may have expired or been revoked. Make a new one and connect it again |

[]()

## Amadeus

- **Reads**: flight status for the flights you name, airline and airport reference data, and flight orders by id.
- **Make**: the API key and secret your Amadeus account manager issued (client credentials). Self-service keys closed on 17 July 2026; enterprise keys reach the same endpoints.
- **Paste**: two lines: the API key, then its secret.
- **Name**: **Environment**, Amadeus’s test host or production.
- Altéa reservations, departure control, inventory and schedules, and NDC orders are [Needs onboarding](/connect/#connectors): our certified forward-deployed engineers map them from your licensed reference.

[]()

## FlightAware AeroAPI

- **Reads**: your operator’s and airports’ flights: schedule, gates, delays, diversions and cancellations.
- **Paste**: an AeroAPI key.

[]()

## Cirium FlightStats

- **Reads**: flight status by airport and by flight.
- **Paste**: two lines: the application ID, then its key.

[]()

## OAG Flight Info

- **Reads**: flight instances by departure airport and date.
- **Paste**: your OAG subscription key.

[]()

## SITA Flight Status

- **Reads**: flight status at your airports, kept current from SITA’s change feed.
- **Paste**: the API key from developer.aero. For OAuth, add the client ID and the client secret on a second and third line.

[]()

## SITA BagJourney

- **Reads**: bags per flight with their loading status.
- **Paste**: the BagJourney API key from developer.aero. BagJourney has no read without a flight, so your deployment checks the key at the first sync.

[]()

## Sabre

- **Reads**: bookings by confirmation id. Travel documents are left out, and only the booking’s traveller count is read.
- **Make**: Sabre’s client credentials.
- **Paste**: two lines: the EPR credential (`V1:user:group:domain`), then its password.
- **Name**: **Environment**, Sabre’s certification host or production.

## Where the credential is held

LightHouse never opens these credentials. They are sealed in your browser, or by `lighthouse-ai connect <provider> --credential-stdin`, to your deployment’s own key, and your deployment keeps them in your own secrets store. LightHouse keeps the connection’s fingerprint, the access level, when it was checked and the check’s code: never the key, and never what it reads. See [Where every credential is held](/connect/#where-every-credential-is-held).

## Removing it

On the card, choose **Disconnect**. Your deployment deletes the credential from your store. Revoke the key at the provider too. Documents already written stay in the corpus until you delete them.

Source: https://docs.atlanticagenticlabs.com/connect/flight-data/