Book and manage tables

Bookings run against the org's connected booking system (e.g. Gastroplanner). You can look up, create, modify, and cancel bookings. startsAt is venue-local time (the system does not expose a timezone) — present it as-is, don't convert it. connectionId is only needed when the org has more than one active booking connection.

Before booking: check availability

Always call bookings_check_availability with the date (YYYY-MM-DD) and partySize before creating a booking — offer the guest real open slots rather than guessing a time. It returns the open time slots (and their seating duration). Creating a booking for an unavailable slot fails with a no-availability error.

Self-service (the guest's own agent)

Every self-service call is fixed to the calling end-user's own identity — you can never act on another guest's booking or book under a different email.

• bookings_list_my_bookings / bookings_get_my_booking — the guest's own bookings.
• bookings_create_my_booking — book a table for the guest. The booking is made under their own email automatically. Pass date, time (HH:MM), partySize; optionally name, phone, note.
• bookings_update_my_booking — change the guest's own booking (date, time, partySize, or note) by bookingRef.
• bookings_cancel_my_booking — cancel the guest's own booking by bookingRef.

If the session has no email identity, these return an error — tell the guest you can't manage bookings in this session and offer a human handover (conv_request_human).

Writes are refused when the message looks forged

Creating, changing or cancelling a booking works on any session that carries the guest's email, the same sessions that can read. The one exception: when you're answering an email and a message in the guest's latest turn explicitly failed its DMARC check for the address it claims to come from, the three write tools return connectors_sender_auth_failed. That result means the receiving mail server saw the From: domain's own policy reject the sender, which is how a forged From: header shows up. It can also be a misconfigured mail relay, so don't accuse the guest of anything.

The write tools also return connectors_sender_forwarded when a message in the guest's latest turn was forwarded — someone sent it on to the support address with the guest's address inside the forwarded text. Munin takes the guest's address from that text, and no mail server has checked it, so it can't be used to change a booking. Forwarding is ordinary (a colleague passing a request along), so treat it like the DMARC case: no accusation.

When you hit connectors_sender_auth_failed or connectors_sender_forwarded, don't retry and don't work around it by calling an admin tool. Tell the guest you can't change the booking from this message and offer a human handover (conv_request_human). Reads keep working, and their replies go to the real owner of the address.

Admin (support agent working a conversation)

• bookings_list_guest_bookings / bookings_lookup_booking — look up by a guest's email (use the verified email of the contact whose conversation you're handling).
• bookings_create_booking — book a table for a guest email.
• bookings_update_booking / bookings_cancel_booking — modify or cancel by bookingRef.

Care with writes

Creating, modifying, and cancelling change the restaurant's live reservation system and (cancel especially) cannot be undone. Confirm the specifics with the guest — date, time, party size, which booking — before you call a write tool, and read back the result.