Bookings

A booking is one element of a trip — a flight, a hotel night, an activity, a restaurant reservation. Moonjar stores each booking in its own typed table with the right fields for that category, so a flight has gates and terminals while a hotel has check-in dates and room types.

How it works

Most bookings arrive by email. Forward a confirmation to your Moonjar address and the email-capture pipeline:

Detects travel intent from the subject and body.
Runs a Claude classifier to decide what kind of booking it is.
Extracts the structured fields for that booking type.
Picks the right trip — existing, or creating a new one if none fit.
Writes the booking and links the source email as a document.

You can also create a booking by hand from the trip detail screen, or have the chat assistant add one in conversation.

Booking types

Each booking type has its own fields. Categories supported:

Flight — carrier, flight number, origin and destination airports, departure / arrival, gate and terminal, status.
Accommodation — provider, address, check-in / check-out, room.
Ground transport — pickup / drop-off, provider, vehicle.
Rail — operator, origin and destination stations, departure / arrival.
Bus / coach — operator, route, departure / arrival.
Ferry — operator, port pairs, departure / arrival.
Cruise — line, ship, ports of call, dates.
Activity — provider, location, date / time.
Show — venue, performance, seating.
Restaurant — venue, party size, time.
Parking — facility, slot, dates.

Adding a new category requires a backend change. From a user perspective the categories are fixed.

What’s tracked across all types

Common fields on every booking, regardless of type:

Booking reference — the confirmation code.
Provider name — who you booked through.
Total cost and currency.
Source email — the original confirmation, if it came in by email.
AI confidence — how sure the classifier was when it pulled the booking out. Low-confidence bookings are flagged for review rather than silently filed.
Notes — free text.

Multi-leg flight journeys

When a flight booking is one leg of a multi-segment journey (e.g. HVB → BNE → MEL), the flight detail screen shows a compact pager strip at the top with one chip per segment. The current leg is highlighted; tap any other chip to jump to its detail screen. Single-segment flights show no pager.

Live status

Some booking types refresh themselves. Flight bookings poll a flight status provider near the departure window so the trip detail screen shows current gate, terminal, and any delay — without you opening the airline’s app.

Pull-to-refresh on a flight booking forces a fresh fetch from the status provider, bypassing the local cache.

Lock-screen tracking (iOS)

Flight bookings on iOS can show as a Live Activity on the Lock Screen and Dynamic Island. The card surfaces the route, the scheduled time, the current status badge (On time / Delayed Xh Ym / Boarding / X% en route / Landed / Diverted / Cancelled), gate / terminal / seat, and — once airborne — a moving progress dot.

The activity starts on its own from about four hours before scheduled departure until 30 minutes after landing. Each flight has its own Lock-screen tracking toggle on the booking detail page, defaulting on. Toggle off and any running activity ends and no new one starts for that flight.

Tapping the lock-screen card or the Dynamic Island opens the booking detail in Moonjar. Lock-screen tracking is iOS-only — hidden on Android and Mac Catalyst.

Limits

Confidence isn’t perfect. A booking that arrives garbled (an old email format, a non-English confirmation, a forwarded three-times-over copy) may end up in the wrong trip or as an orphan booking awaiting your routing decision.
Cost extraction is best-effort. If the email doesn’t list a total, Moonjar leaves it blank rather than guess.
Live flight status depends on a configured flight-status provider. Without one, the booking shows the static data from the email and nothing more.