Deskie Access is Deskie's built-in door provider. Instead of relying on a third party, it talks directly to a relay controller at your space over its local API. Each relay corresponds to a numbered channel, and each channel maps to a door (for example a front entrance or a suite). From Deskie you can unlock those doors, decide which members are allowed to open which doors, and review a record of every door action that has happened. This article explains how those pieces fit together.
Deskie Access is one of several door integrations Deskie supports. For how it compares to the others and the general concepts shared across all of them, see Door access overview.
How Deskie Access connects to your controller
Deskie Access communicates with a relay controller installed at your location. The connection is configured with three values stored in your workspace settings: a host, a port, and an API key. When Deskie needs to act on a door it builds the controller's address from the host and port, then sends each request with your API key attached so the controller knows the call is authorized.
There is a built-in connection test you can run from settings. It checks each value in turn and tells you what is missing or wrong: it reports separately when the host, port, or API key has not been filled in, and it interprets controller responses to return clear messages such as an invalid API key, an unreachable controller (check host and port), or a timed-out connection. When the test succeeds it confirms the connection and reports how many relays the controller found, which is a quick way to verify the controller is wired up and responding.
Every request Deskie makes to the controller has a short timeout, so if the controller is offline or unreachable the action fails quickly with a readable error rather than hanging.
Doors are relays on channels
The controller exposes its doors as relays. Each relay has a channel number, a current state (on or off), a label, and a default pulse duration. The label is the human-readable door name you see throughout Deskie, and the default pulse duration is how long that door stays released when it is pulsed.
Channels run from 1 through 8. Deskie validates the channel on every door action and rejects anything outside that range, so a malformed request can never reach the controller. Workspace administrators can rename a door and change its default pulse duration from Deskie; these settings are written back to the controller for that channel.
Unlocking a door: pulse, hold open, and lock
Deskie Access supports a few distinct door actions, each suited to a different situation.
- Pulse is a momentary unlock and the primary way to grant entry. It releases the door for a brief moment and the door re-locks on its own. If no duration is supplied the controller uses that door's default pulse duration. A custom duration can be supplied, and Deskie validates that it falls between 100 milliseconds and 30 seconds.
- Hold open energizes the relay so the door stays unlocked until it is explicitly locked again. This is an administrator-level operation: it requires the manage-workspace permission. Use it for situations like propping a door open during an event.
- Lock turns the relay off for a single door, returning it to its locked state. This is the counterpart to hold open.
- Lock all is an emergency lockdown that locks every door at once. Like hold open, it requires the manage-workspace permission.
There is a safeguard on pulsing. If the person triggering the unlock is a paused member, the unlock is refused. Workspace owners and admins are exempt from this check so they can still operate doors for diagnostics. Pausing a member therefore cuts off their ability to open doors through Deskie Access. For more on what pausing affects, see Pausing and disabling members.
Granting door access to members
Access in Deskie Access is granted per member, per door. There are no access groups; you choose, for each member, exactly which doors they are allowed to unlock. You manage this from a member's Access tab, on both the member detail page and the edit-member form, where Deskie shows a list of every door on the controller with a toggle beside each one.
Each toggle saves immediately. Turning a door on grants that member access to that channel; turning it off revokes it. Revoking does not delete the underlying record, it simply disables the grant, so an administrator can flip a door back on later without starting over. Granting the same door twice is harmless because each member can have only one grant per channel.
Granting and revoking door access requires the manage-members permission. Members cannot change their own grants. The grant record also stores the door's name at the time it was set, so the record stays readable even if the door is later renamed.
What members see
Members only ever see the doors they have been explicitly granted. On the member access page, Deskie looks up the member's enabled grants, fetches the live relay information from the controller, and shows only the doors whose channels the member is allowed to open. A member with no grants sees no Deskie Access doors at all.
From there a member can pulse a granted door to let themselves in. Deskie also supports a buzz-in flow reached by a per-door link (for example tapped from an NFC tag at the entrance): opening that link for a valid channel fires a pulse immediately and shows whether the door unlocked. The buzz-in flow still requires the member to be signed in and the integration to be configured, and it is subject to the same paused-member safeguard as any other pulse.
The access log
Every door action Deskie Access performs is recorded in a shared access log. Each entry captures what happened (pulse, hold open, lock, unlock, or lock-all), which channel and door label it affected, who triggered it, and where it came from. The source field distinguishes how the action was initiated: from the admin door table, from a door card, from a buzz-in link, or automatically from a schedule. The door's label is stored on the entry so the record stays accurate even if the door is renamed afterward.
Logging is best-effort and never blocks the door itself. If writing the log entry fails for any reason, the door action still completes; the failure is recorded internally rather than surfaced to the person at the door. When an unlock, pulse, or hold-open action is tied to a specific member, it also appears on that member's activity timeline, labeled with the provider name (Deskie Access) and how it was triggered. For more on the timeline, see Member activity and billing.
Administrators can review the access log for the workspace, optionally filtered to a single door, with the most recent actions shown first.
Scheduled and booking-driven unlocking
Beyond on-demand unlocks, Deskie Access can hold doors open automatically. Each door can have a weekly schedule with a per-day enable toggle and a start and end time. When the current local time in your workspace's timezone falls inside an enabled window, Deskie holds that door open; when the window ends, Deskie locks it again. Schedules are evaluated by a recurring background job, and Deskie validates that each enabled day's start time comes before its end time. Editing a door's schedule requires the manage-workspace permission. For the full walkthrough, see Door scheduling.
The same automation also responds to bookings. When a resource is set to auto-unlock specific Deskie Access channels and a confirmed booking is currently in progress, those channels are held open for the duration of the booking and then released, with the booking's member and resource recorded on the resulting log entries. This ties physical access to a reservation so a member's booked room is open exactly when they need it. See Resource access rules for how to attach doors to a resource.