A hotel runs on its property management system (PMS): reservations, room status, billing and housekeeping all live there. Yet at most properties the door lock still sits outside that workflow, forcing the front desk to cut keys, encode cards and manually expire them. Connecting access control to the PMS closes that gap — a confirmed booking provisions a guest credential automatically, and check-out removes it.
Why connect the locks
When locks and the PMS are connected, the guest credential lifecycle runs on booking events instead of manual steps. Check-in friction at the front desk disappears, because a code or mobile key exists the moment a reservation is confirmed and the guest can go straight to the room. Expiry becomes automatic and reliable — the credential dies at check-out with no staff action, so the most common security lapse, a card forgotten in a drawer, cannot happen. Every entry is logged against a room and a guest, which resolves disputes and supports investigations. Housekeeping, maintenance and managers get their own time- and door-scoped credentials, independent of the guest flow. Staff also operate one system instead of two: rooms in the PMS they already know, with access following automatically.
What the integration does in practice
The integration keeps two records in sync: the booking in the PMS and the credential on the lock. On check-in it provisions access, during the stay it logs guest and staff entries, and on check-out it revokes. Because authorisation happens on the lock itself, the door still works if the PMS or the network is briefly down.
How it is built: API and webhooks
A modern access platform exposes two integration channels, and a good hotel connection uses both.
The REST API is for commands. The PMS calls it to create, modify and revoke credentials, and to read unlock logs — generate a time-limited passcode or e-key on a specific lock, set the validity window from check-in to check-out, bind the credential to a guest identity for a meaningful audit trail, revoke it immediately on early check-out or a problem guest, pull entry logs for reporting or dispute resolution. This is the same capability the Sciener platform exposes; for a closer look at the underlying model, see the TTLock app integration guide.
Webhooks are for events. Where the API is the PMS asking the lock platform to do something, a webhook is the platform telling the PMS something happened: a guest unlocked a door, a lock went offline, a battery is low. The PMS reacts in real time — marking a room occupied, flagging a low-battery door for maintenance, alerting security to an anomalous entry. Together they form a closed loop: the PMS commands access, and the locks report back.
What to settle before you build
Most integration problems are data problems, not technology. The room-to-lock mapping has to be unambiguous: every PMS room number maps to one physical lock ID, validated door by door and versioned when rooms are renumbered. Guest identity needs a single unique key — booking reference, name, or phone — used consistently so logs stay meaningful and revocable. The credential needs a fallback, because a dead phone should never lock a guest out: a passcode keypad covers the common case, a mechanical key the worst case. Times live in one time zone and convert only for display, since a check-out window off by an hour strands a guest. And there has to be a documented manual override path, decided before launch rather than after a failure.
| Planning item | What to decide | Why it matters |
|---|---|---|
| Room-to-lock mapping | One lock ID per PMS room | Prevents provisioning the wrong door |
| Guest identity | Unique key (booking ref or phone) | Keeps audit logs accurate and revocable |
| Credential + fallback | Primary code/key plus a backup | A dead phone never locks a guest out |
| Validity window | Check-in to check-out, single time zone | Avoids premature expiry or over-stays |
| Failure mode | Manual override plus contacts | Recovers gracefully when systems are down |
Roll out in phases
Treat the integration like any operational change: pilot, then expand. Connect a single floor's locks to the PMS and run live guests through it for a few weeks — mapping errors, timing bugs and edge cases surface cheaply here. Train staff before you scale: front desk, housekeeping and maintenance should understand the flow, know where to look when something seems wrong, and how to issue a manual override. Watch the first month closely, looking for failed provisioning, codes that did not expire, or doors reporting offline — each is a small fix now and a major incident later. Once the pilot is stable, expand floor by floor, re-validating the mapping as you go.
A gateway on each floor keeps the locks reachable for remote commands while preserving the on-device authorisation that makes the system reliable. For the guest-credential mechanics in detail, read about temporary access codes for guests.
Connecting access control to a hotel PMS takes manual key handling out of the picture. Expiry becomes automatic, and every door entry has a verifiable audit trail behind it. The technology — a REST API for commands and webhooks for events — is well established, so most of the effort goes into mapping, identity, fallbacks and a careful phased rollout. Get those right and check-in stops being something the front desk has to manage. To scope an integration for a specific property, contact Sciener.