Physical Access
Physical access controls how members get through doors at Metrognome locations. Each member has a personal PIN code that is programmed to the relevant locks when they have an active reservation, and removed when access should end.
Access Codes
Every member has a single 6-digit PIN code. One active code per member at a time. Codes are reused across all of a member's reservations — they don't get a new code for each booking.
Custom codes can be set (must be 4, 6, or 8 digits). When a custom code replaces an existing code, the old code is expired and the new one is programmed to all relevant locks.
Codes exist in the database independently of lock programming. A code being "active" in the database means it's the member's current PIN — it doesn't mean it's programmed to any specific lock at that moment.
Access Gates
Access gates are the configuration layer connecting physical locks to studios. Each gate represents a single lock device and specifies which vendor operates it, and what it controls.
Gates can be scoped to:
- A specific resource — the studio's own door
- A resource group — a shared entry point (wing door, floor entry, parking gate, building entrance)
When a reservation is created, the system finds all gates that apply to that resource — both direct resource gates and gates on any resource group the resource belongs to. The member's code is programmed to all of them.
Vendors
Three types of lock hardware are supported:
- Schlage — smart locks, typically on individual studio doors. Connected via cloud service.
- Unifi (Ubiquiti) — enterprise access control for main entries and common areas. Connected to a local controller.
- Manual — standard keypads without smart integration. A static code is configured on the gate and shown to members, but not programmed automatically.
Monthly vs Hourly Access
Access works differently depending on reservation type:
Monthly lockouts have permanent access — the code is programmed with no expiration. For Unifi hardware, monthly members are added to a persistent "members group" at the location rather than getting individual time-windowed policies. The code stays active as long as the subscription is active.
Hourly reservations have time-windowed access — the code is programmed shortly before the reservation starts and removed when it ends. For Unifi hardware, this creates a temporary access policy with a specific time window.
Tours receive no access codes at all.
When Codes Are Provisioned
Access code programming happens asynchronously via background jobs, not in real-time. Jobs are scheduled to run 15 minutes before the reservation's start time. For future-dated monthly lockouts, provisioning is deferred until the billing period begins.
Multiple jobs for the same lock are serialized to prevent race conditions — a new job waits for any pending jobs on the same device to complete first.
When Codes Are Revoked
Access codes are revoked in several scenarios:
- Reservation cancellation — codes for that reservation are deleted from all applicable locks. For monthly cancellations, the member is also removed from the building security group if they have no other active lockouts at the same location.
- Subscription deletion (after Stripe's dunning cycle) — same as cancellation: codes deleted, security group membership revoked if no other active lockouts at the location.
- User banned (approved set to false) — all codes for the user are revoked across all locations and all gates. Security group membership is also revoked.
- Studio transfer — old studio's codes are deleted, new studio's codes are provisioned.
Access is NOT revoked on payment failure alone — only when the subscription is actually deleted.
Members Group (Unifi)
Each location using Unifi hardware can have a "members group" — a pre-configured group in the Unifi system that grants permanent access to the appropriate doors. Monthly lockout members are added to this group instead of getting individual time-windowed access.
A member is removed from the group only when they have no remaining active monthly lockouts at that location. If they have multiple lockouts at the same location, they stay in the group until the last one ends.
Failure Handling
Lock programming jobs retry up to 5 times with exponential backoff (5 seconds base, capped at 5 minutes). If a code already exists on a Schlage lock with the same identifier, the job retries until the conflict clears.
Unifi operations have additional provider-level retries for network errors and rate limiting. If a Unifi access policy deletion fails after all retries, a critical alert is raised since orphaned access may persist.
Code revocation failures (e.g., removing from the members group) are logged but do not block the cancellation flow — the cancellation proceeds even if lock cleanup fails.