Deskie controls physical doors through one or more access providers that you connect to your workspace. Once a provider is connected, you can see your doors inside Deskie, grant access to members, let bookings and passes open doors during their valid window, and unlock doors remotely. This article explains the providers Deskie supports, how access is decided, when it expires, and the different ways a door can be unlocked.
Supported providers
Deskie supports three door access providers. A workspace can have any combination of them connected at once, and the access page shows doors from every provider you have configured. If none are configured, Deskie shows a "No Door Access Currently" empty state.
Deskie Access
Deskie Access is Deskie's own door controller. It talks directly to a relay controller on your network over HTTP using a host, a port, and an API key. Each physical door maps to a relay channel (channels 1 through 8), and every channel has a label and a default pulse duration. From Deskie you can:
- Pulse a door, which is a momentary unlock and the normal way to let someone in. The pulse length is measured in milliseconds and is bounded between 100ms and 30000ms.
- Hold a door open, which energizes the relay so the door stays unlocked until it is explicitly locked again. This is an admin-level action.
- Lock a single door, or trigger an emergency lock all across every door at once. Locking all doors is an admin-level action.
Deskie Access also supports per-door schedules and booking-driven auto-unlock, which are covered under door scheduling.
Kisi
Kisi is a cloud access platform that Deskie connects to with a single API key. Kisi organizes hardware into places, locks, and groups. In Deskie, a member is given Kisi access by being placed in a Kisi place or added to a Kisi group, which is what associates them with the locks that group can open. Because Kisi is cloud based, it also supports mobile unlocking and time-bound access for visitors, which the other providers handle differently.
UniFi Access
UniFi Access is Ubiquiti's on-premise access system. Deskie connects to a UniFi Access controller using a host address and an API key. Many UniFi controllers run with self-signed certificates on the local network, and Deskie is built to handle that case when reaching the controller. UniFi organizes access into doors and user groups, and supports NFC cards that can be assigned to a specific user for tap entry. In Deskie, a member is given UniFi access by being added to a UniFi user group and by enabling specific doors for that member.
How members get access
Member door access is managed per member and per provider, and it is set up by an admin rather than purchased. The mechanism differs by provider:
- Kisi: the member is created as a Kisi user and added to one or more Kisi groups (or assigned to a place). Their accessible doors are the locks attached to those groups.
- UniFi Access: the member is created as a UniFi user, added to a UniFi user group, and then specific doors are enabled for them. Deskie records which doors are enabled for each member so it can show the member exactly the doors they can open.
- Deskie Access: the member is granted access to specific relay channels. Each grant records the channel and the door name, and can be toggled on or off without removing it, so an admin can revoke access and later re-enable it.
When a member opens their access view, Deskie only shows the doors they have actually been granted, not every door in the space. Admins and owners, by contrast, see every door across every connected provider. Guests see only the doors that are temporarily available to them, described next. See Deskie Access for setup details and managing members for where per-member access is configured.
How bookings, passes, and events grant access automatically
Beyond standing member access, Deskie can surface a door temporarily while someone has an active reason to be in the space. This automatic, time-bound access is provided through Kisi locks and is what makes a door appear for a visitor, day-pass holder, or event attendee only while their access is valid.
For this to work, the resource, pass type, or event must have door access enabled and have specific Kisi locks attached to it. Deskie then grants access in these situations:
- Bookings: a confirmed booking on a resource that has door access enabled surfaces that resource's Kisi locks while the booking is currently in progress. The access window runs from the booking start time to the booking end time.
- Passes: a pass that has door access enabled surfaces its Kisi locks on the day the pass is used or scheduled. Pass-based door access runs from midnight to midnight on that date, and the pass must still have remaining uses.
- Events: a confirmed event ticket for an event that has door access enabled surfaces that event's Kisi locks while the event is currently happening, from the event start time to the event end time.
Deskie aggregates all of these sources, so a person who has, for example, both an active booking and an event ticket sees every door that any of their active reasons unlocks. If none of a person's bookings, passes, or events are currently active, no doors are surfaced to them. Related reading: booking a resource, passes, and events.
Deskie Access handles booking-driven access differently: a resource can be configured to auto-unlock specific Deskie Access channels, and a scheduled job opens those channels while a confirmed booking is in progress and locks them again once no booking or schedule still requires them. This is detailed in door scheduling.
When access expires
Automatic access is always bounded by a valid-from and valid-until window, so it ends on its own without an admin revoking anything:
- Bookings grant access only between the booking's start and end times.
- Events grant access only between the event's start and end times.
- Passes grant access for the full day they are used or scheduled, from midnight to midnight. Separately, a purchased pass can carry its own expiration date based on the pass type's expiration setting, after which the pass itself is no longer active and cannot grant access.
Standing member access does not expire on a timer. It remains in effect until an admin removes the member from the relevant Kisi or UniFi group, or disables their Deskie Access channels. One important runtime rule applies across all providers: if a member is paused, Deskie refuses their unlock attempts. Owners and admins can still unlock for diagnostics even while a member is paused. See pausing and disabling members.
Ways to unlock a door
Depending on the provider and how access was granted, a door can be opened in several ways.
Remote unlock from Deskie
From the access view, an authorized person can unlock a door directly:
- Kisi locks are unlocked through the Kisi API.
- UniFi doors are unlocked through the UniFi Access controller.
- Deskie Access doors are pulsed (momentary) for normal entry, held open, or locked, with admin-only controls for holding open and for locking all doors.
Every remote unlock is recorded in Deskie's access log with the door, the person who triggered it, and the source, so you have an audit trail. Schedule-driven and booking-driven unlocks on Deskie Access are also logged, attributed either to the schedule or to the member whose booking opened the door.
Kisi mobile unlock
Kisi supports unlocking from a member's phone. For workspaces with Kisi connected, Deskie can provision a per-user Kisi login behind the scenes so the Deskie mobile app can unlock Kisi locks on that member's behalf using Kisi's unlock SDK. The login is provisioned only after an admin has set the member up as a Kisi user; Deskie does not create the Kisi user automatically.
UniFi NFC cards
UniFi Access supports physical NFC cards. A card can be assigned to a specific member for tap entry at the reader, and unassigned later when it is no longer needed.
Scheduled auto-unlock
Doors can be set to unlock automatically on a recurring weekly schedule, for example to keep a main entrance open during business hours, and lock again outside those hours. Scheduling is available for Deskie Access and Kisi locks and is covered in detail in door scheduling.
Guardrails for member unlocks
Remote unlock is convenient, but it also means a member can open a door from anywhere, including for people who should not be let in. For Kisi workspaces, Deskie offers guardrails that put Kisi's own restriction engine back in charge and alert you to suspicious unlock patterns. Both live in Settings under Door Access and are off by default.
Enforce Kisi restrictions on member unlocks
Normally Deskie unlocks Kisi doors using your workspace's admin API key, and Kisi exempts admin-key requests from its restriction engine. That means a member unlocking from the web could bypass restrictions such as reader proximity. With Enforce Kisi restrictions on member unlocks turned on, member unlocks are performed under the member's own Kisi identity instead, so Kisi enforces their access grants, time restrictions, and reader proximity server-side, exactly as it does in the Kisi app. Owners, admins, and staff with door access keep the admin key, so remote unlock keeps working for your team.
With enforcement on, a member whose unlock violates a Kisi rule gets a clear error, for example that they need to be at the door. The member must be set up as a Kisi user for their unlocks to work in this mode, which is the same requirement as Kisi mobile unlock above.
Reader proximity, per lock
Each Kisi lock's detail page in Deskie has a Restrictions card with a Reader proximity switch. When enabled, users must be physically at that door's reader to unlock it. Kisi enforces this for member unlocks when restriction enforcement is on; admins are exempt. The card also shows any geofence or time restrictions configured on the lock.
Rapid unlock alerts
Turn on Alert admins on rapid unlocks and Deskie watches for the same door being unlocked many times in a short window, a common sign that someone is buzzing in a stream of guests. You choose the threshold and the window, for example 5 unlocks in 10 minutes, and when a door hits it your admins are notified by push and SMS, with email available as an opt-in under notification preferences. Admin unlocks never count toward the threshold, and a sustained burst produces one alert rather than one per unlock.
Reliability and connection handling
Each provider is reached over the network, and an unreachable controller should never block the rest of Deskie. Calls to door hardware use short timeouts, and if a controller cannot be reached (for example an offline UniFi controller or a Deskie Access box that is not responding), Deskie reports a clear connection error rather than hanging. On the access page, an integration that times out simply contributes no doors instead of breaking the page. For Deskie Access and UniFi Access, Deskie can test the connection and tell you whether the issue is a bad API key, an unreachable host or port, or a timeout, so you can correct the setup quickly.