Open a meeting room door for the people who booked it
Nobody scans anything at a meeting room door — your access control system has to know in advance who booked the room and when. Store each person's card number, subscribe to booking changes, and turn them into a door permission.
A lobby gate and a meeting room door are not the same problem. At the gate a visitor holds up a badge and your reader asks Offision whether it is good — see Open your gates with an Offision visitor badge. At a meeting room door nobody scans anything. Somebody walks up holding the staff card they carry every day, and the door has to already know that they booked this room for this hour.
So the flow runs the other way: Offision tells your system about the booking in advance, and your system turns it into a permission before anyone arrives.
1. Store each person’s card number
Put the number from their staff card against their Offision user with the set access card call
(UserCard, UserCard2 or UserCard3, so somebody can carry more than one), and clear it with
remove access card when the card comes back.
Without this the room opens for nobody: a booking names people, and a door reads cards, and the card number is the only thing that joins them. The same numbers can be issued and imported by hand in the console — see How access cards work.
2. Subscribe to booking changes
Register the resource appointment subscription, giving your callback URL and the resources you care about. Offision posts to that URL when a booking on them is made, moved or cancelled.
3. Turn each callback into a permission
On each callback, match the bookable resource id to the door your side controls, read the organiser and attendees, and turn their card numbers into a permission for that window.
Then re-read the day with the resource appointment query whenever your side reconnects. Treat the callback as a nudge and the query as the truth — a missed callback is otherwise invisible, and a door that quietly stopped being told about changes looks exactly like a door that is working.
4. If the door takes a code rather than a card
The bookable resource access keys are the other route: read a room’s one-time, daily or static keys, and subscribe to the daily and one-time keys to be pushed each new one as it rotates.
5. Check it worked
- Book the room yourself, then confirm the permission appeared on your side before the start time — not at it.
- Move the booking an hour, and confirm the permission moved with it.
- Cancel it, and confirm the permission was withdrawn. This is the one people skip, and it is the one that leaves a door open to somebody who no longer has the room.
- Add an attendee, and confirm they can open the door too.
When it goes wrong
| What you see | Usual cause |
|---|---|
| Callbacks fire for an hour, then stop | The subscription expired. It lasts 60 minutes by default and a day at most, and has to be renewed |
| The door opens for the organiser but not the attendees | Only the organiser has a card number stored against their user |
| Permissions drift out of step after a network blip | Nothing re-reads the day on reconnect. A missed callback reports no error |
| Every call returns 403 | The credential is missing user.readwrite or bookableResource.read |

