# Check guests in from your own system

> Read the day's manifest and mark guests as checked in or no-show from your own app or scanner.

Source: https://www.panion.travel/docs/guides/check-ins

Your key needs `manifest:read` and `checkins:write`. Tick both when you create it in Oracle (**Settings > API keys**). Write scopes are off unless you tick them.

**Step 1. Read the manifest**

Every departure on a day with its passengers, from every channel. Each passenger row has an `id` and its check-in state.

```sh
curl "https://www.panion.travel/api/v1/manifest?date=2026-11-02" \
  -H "Authorization: Bearer $PANION_API_KEY"
```

**Step 2. Check a booking in**

Send the passenger `id`. Add `present` for a partial party (3 of 4). Use a new `Idempotency-Key` per action.

```sh
curl -X POST "https://www.panion.travel/api/v1/manifest/<id>/checkin" \
  -H "Authorization: Bearer $PANION_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"status": "checked_in", "present": 3}'
```

**Step 3. Mark a no-show or undo**

Send `{"status": "no_show"}`, or `{"status": "clear"}` to return the row to not seen.

> Only the check-in is stored. The booking, its guests and its money never change, and your booking system is not told.

## Good to know

- Up to 2000 check-ins per key and UTC day by default. Past it: 429 with `Retry-After`.
- The manifest reads a mirror of your booking system, refreshed nightly and every two hours for near-term departures.
- Guest email and phone only appear with the `guests.contact:read` scope.
- No code? Your AI assistant can do the same through the [MCP server](https://www.panion.travel/docs/mcp).

Full fields: [Manifest](https://www.panion.travel/docs/api/reference/manifest) and [Writes](https://www.panion.travel/docs/api/reference/writes).