Skip to content

✅ Door Access Synced

Topic: RESERVATION_DOOR_ACCESS_SYNC_SUCCESS

What It Does

The doors stored on a reservation changed after a successful interaction with the door access provider. The event carries the change as patches, so a subscriber can keep track of exactly which doors a guest can open.

Key Info

  • Object: Reservation
  • Actors: Guest or Staff
  • Source: BACKOFFICE, GUEST_JOURNEY, PLATFORM, PMS

When It Fires

Only when the stored doors changed. A sync whose result equals what is already stored (for example a manual re-sync of the same state from the backoffice) does not emit an event. Triggers:

  • After pre-checkin completion
  • After check-in completion
  • After check-out
  • After room assignment
  • After amend stay
  • After a backoffice or Public API sync

If the provider failed, Door Access Sync Failed fires instead, also when the automatic recovery changed the stored doors.

Context Data

⚠️ context.request is deprecated and will be removed on December 31, 2026. Read the top level fields instead.

{
    "requestor": "KEYS_IN_HOUSE",
    "doorAccessState": "PUBLIC_AND_PRIVATE",
    "patches": [
        {
            "op": "add",
            "path": "/accessibleDoors/1",
            "value": {
                "id": "8D9378B2CA5D2FCC6D8008D934ABA012",
                "title": "216",
                "lockAccessibility": "PRIVATE"
            }
        }
    ],
    "request": {
        "reservationId": "ABCDEFGH-1",
        "doorAccessState": "PUBLIC_AND_PRIVATE",
        "requestor": "KEYS_IN_HOUSE"
    }
}
Field Description
requestor What triggered the sync, see Requestors
doorAccessState The access state the sync reached, see Door Access States. Not set for KEYS_REFRESH and WALLET_ADD
patches JSON Patch from the previous to the new reservation, door changes under /accessibleDoors
request Deprecated, removed on December 31, 2026. Legacy copy of the sync request (id, reservationId, doorAccessState, requestor, principal). Use the top level fields instead
user The staff member who triggered the sync. Only present for syncs started from the backoffice

Door Access States

State Description
NONE No door access granted - guest cannot access any doors
PUBLIC Access to public areas only (lobby, common areas)
PUBLIC_INHOUSE Access to public areas for checked-in guests
PUBLIC_AND_PRIVATE Full access to both public areas and private room/unit

Requestors

Requestor Description
CHANGE_PIN Guest requested PIN code change through self-service
ADMIN Staff manually triggered sync from backoffice
KEYS_CONFIRMED Guest completed pre checkin and on arrival day public doors are issued
KEYS_CONFIRMED_TIMER Guest completed pre checkin and on arrival day public doors are issued by timer
KEYS_FORCE_PRIVATE_TIMER Automatic sync triggered by private access timer
KEYS_IN_HOUSE Sync triggered when guest checks in (in-house status)
KEYS_FORCE_IN_HOUSE Force sync for in-house guest (override existing state)
KEYS_CHECKED_OUT Legacy, no longer emitted. Replaced by KEYS_CLEANUP_CHECKED_OUT
KEYS_SYNC General door access synchronization request
KEYS_REFRESH Nightly refresh of the stored doors from the provider
KEYS_CLEANUP_CHECKED_OUT Guest checked out, private doors removed and public doors kept
KEYS_CLEANUP_FINAL All doors removed after the stay ends, a cancellation or a no-show
WALLET_ADD Guest added a key to their mobile wallet

What To Do With It

  • Apply patches - Keep your own copy of the guest's doors current
  • Notify guest - Keys are ready to use
  • Confirm access validity - Verify access times are correct
  • Log sync success - Track for operational metrics
  • Enable access notifications - Alert on door usage if configured