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.

Updated 30 Aug 2026

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 seeUsual cause
Callbacks fire for an hour, then stopThe 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 attendeesOnly the organiser has a card number stored against their user
Permissions drift out of step after a network blipNothing re-reads the day on reconnect. A missed callback reports no error
Every call returns 403The credential is missing user.readwrite or bookableResource.read