Pre-arrival guest communication

A guest hasn't arrived yet to the property. Use getReservations with parameters checkInFrom and checkInTo to see the arrivals for any period.
You may also subscribe to our Webhooks to receive a notification when a new reservation was created.

In-house guest communication

A guest is staying at the property. Get the reservation and guest data getReservations with parameter status=checked_in.
You may also subscribe to our Webhooks to receive a notification when a reservation changes status to checked_in.

A guest is scheduled to depart on a specific date. To get guest and reservation data of departing guests use getReservations with parameters checkedOutFrom and checkedOutTo To get reservations/guests that have been checked out add parameter status=checked_out.
You may also subscribe to our Webhooks to receive a notification when a reservation changes status to checked_out.

To post a reservation note use postReservationNote or if the note applies specifically to a guest post a guest note with postGuestNote. Notes can be posted regardless of the reservation status.

Use postEmailTemplate to create an email template with the same custom field. Myfrondesk will send out the email to the guest.
Use postEmailSchedule to schedule the template either based on the reservation status change or a date.

Use getReservations with the parameters indicated above depending on if pre / during or post communication (at least one of them).*
You may also subscribe to our Webhooks to receive a notification when a new reservation was created.*

Webhook: reservation/created — payload includes reservationID, startDate, endDate, propertyID

Confirmed → your system updates status
Not confirmed → your system updates status
Checked in → your system reflects check-in (and any downstream logic, e.g. room status)
Checked out → your system reflects check-out
No-show → your system reflects no-show
Canceled → your system reflects cancellation (distinct handling from delete, see #5)
Status change triggered by staff in the PMS UI
Status change triggered by a system process or API

Webhook: reservation/status_changed — payload includes status, reservationID

Extending length of stay (later end date)
Shortening length of stay (earlier end date)
Shifting both start and end dates (same length, different dates)
Date change on a single-room reservation
Date change on a multi-room reservation (verify subReservations array reflects each affected room's new dates individually)

Webhook: reservation/dates_changed — payload includes subReservations[] (per-room id, startDate, endDate)

Room reassignment within the same room type (e.g. Room 101 → Room 102)
Room type change (e.g. Standard → Deluxe)
Unassigning a room (room removed, reservation stays unassigned)
Accommodation status toggles occupied/unoccupied independent of reservation status
Verify accommodation_type_changed triggers a follow-up accommodation_changed event (documented dependency — expect duplicates/related events, don't treat as an error)

Webhooks:

reservation/accommodation_changed — room/unit reassignment, includes roomId, roomIdPrev, subReservationId
reservation/accommodation_type_changed — room type change, includes roomTypeId, subReservationId
reservation/accommodation_status_changed — includes status (occupied/unoccupied), roomId

Full reservation deleted → your system removes/archives the entire reservation
Deletion is distinct from cancellation (canceled reservations still exist with status: canceled; deleted reservations are gone)
Deleting one room from a multi-room reservation does not delete the parent reservation

Webhooks:

reservation/deleted — full reservation deletion, includes reservationId
reservation/accommodation_removed — single sub-reservation (room) removed from a multi-room booking; parent reservation persists. roomId is null if the removed accommodation was unassigned

Creating a reservation with 2+ rooms generates correct subReservations/subReservationId values for each room
Status change applied to the whole reservation reflects consistently across all rooms
Date change applied to only one room in the group (if supported) updates only that subReservation
Room type change on one room in the group doesn't affect the others
Removing one room (accommodation_removed) leaves the remaining rooms/parent reservation intact
Guest assignment/removal per room is handled independently (guest/assigned, guest/removed, both carry roomID)

A reservation split into multiple stay segments (e.g. guest moves rooms partway through) generates the expected sequence: accommodation_changed and/or accommodation_type_changed plus dates_changed for the affected subReservationIds
Your system correctly reconstructs the split reservation
No duplicate guest profiles/occupancy are created when the split occurs