Door & Gate Access

Physically actions a Door & Gate Access door controller. Get doorId from door_access_doors_read list; never guess it.

Actions:

• unlock: Unlock a door. Admin override: bypasses member rules, force-closed maintenance and blockAllAccess, holds the relay for the door's hold time, relocks by itself and writes an audit row. Sent without waiting for the device; returns commandId, eventId, holdTimeSeconds and bypassedMaintenanceMode. Needs reason. Asks for confirmation.
• identify: Beep to locate a door. Plays about 2 seconds of beeps on the controller so someone on site can find it. No audit row.

Door controllers at a facility in Door & Gate Access, the doors members unlock from the Performance Hub app. Use list to find a doorId and see which doors are online, in maintenance or blocked, and which rules, geofence and Access Policies apply; use device_status to troubleshoot one controller. Adding or removing controllers is done in Device Management.

Actions:

• list: List doors. Each door with online state, maintenanceMode, blockAllAccess, Access Scope groupIds, overrides, effective rules and time-window access, Access Policies, auto-unlock schedule and device settings.
• device_status: Door device status. Telemetry for one controller: update status, IP and network, Wi-Fi SSID, hardware, OS and app versions, uptime, CPU and memory. deviceStatus is null when it has reported none. Needs doorId.

Changes a Door & Gate Access door's safety, geofence and device settings. Who may unlock is set with Access Policies (door_access_settings_write), not here. Read the door with door_access_doors_read list first.

Actions:

• configure: Configure a door. Only the fields you pass change; null clears. Device settings are pushed to the controller straight away, and an autoUnlockSchedule change briefly restarts door control on the controller. Holding a door open or blocking it asks first. Needs doorId. May ask for confirmation.

The Door & Gate Access audit trail at a facility, newest first: who tried to unlock which door, when, and whether it worked. Use it to answer who opened a door, why someone was denied, or to audit admin overrides.

Actions:

• door_events: Door events. Each attempt with doorId, personID (a User Access userId, or the admin's email for overrides), outcome and denial reason, source, geolocation result and user agent.
• no_visit_recorded: Windows with no visit. Elapsed one-time time windows of a single user with no successful unlock (missed bookings). Weekly windows and policy schedules aren't included.

A facility's Door & Gate Access Settings: Access Policies (who may open which doors, and when), Access Scopes (named door groups), app and geofence rules, and automated app messages. Change them with door_access_settings_write; sync settings are in door_access_sync_read.

Actions:

• rules: App and geofence rules. The settings document: geofence, accessTimeWindowGrace (early and late minutes on every window), appLock, supportContacts and the facility appMessage.
• policies: Access Policies. The versioned Access Policies document: each policy has an audience (who), targets (doors and scopes) and an anytime or scheduled window set. Keep its revision for writes.
• policy_impact: Access Policy impact. How many people and doors one policy reaches now; check before editing or deleting it. Needs policyId.
• test_geofence: Test the geofence. Whether an unlock at this position would pass the facility (or one door) geofence. Changes nothing. Needs lat, lng.
• scopes: Access Scopes. Named sets of doors that policies target and grants name, with doorIds and geofence override. A door can be in several.
• scope: Get an Access Scope. Needs groupId.
• auto_messages: Automated app messages. Rules that set a person's app message from their membershipStatus, type, tag or doorVisibility (none or some). Manual messages and decoupled or suppressed people are never overwritten.
• auto_messages_sweep_status: Automated message sweep. Progress of the re-evaluation that runs after the messages change: status queued, running, done or error, with users scanned and updated. sweep is null before the first one.

Changes a facility's Door & Gate Access Settings: Access Policies, Access Scopes, app and geofence rules, and automated app messages. Read the current state with door_access_settings_read first; policy writes need its revision and return 409 when someone else changed them since.

Actions:

• update_rules: Save app and geofence rules. Send back the whole document from door_access_settings_read rules with your changes. Authorization fields are kept server-side; change access with Access Policies. Needs rules.
• update_policies: Replace all Access Policies. Atomically replaces the whole document; prefer the single-policy actions. Needs accessPolicyConfig. Asks for confirmation.
• create_policy: Add an Access Policy. Needs policy, revision.
• update_policy: Edit an Access Policy. Replaces one policy; the others are untouched. Needs policyId, policy, revision.
• duplicate_policy: Duplicate an Access Policy. Needs policyId, revision.
• delete_policy: Delete an Access Policy. Needs policyId, revision. Asks for confirmation.
• create_scope: Add an Access Scope. Needs name.
• update_scope: Edit an Access Scope. Only the fields you pass change. Changing doorIds changes who can open those doors: check door_access_settings_read policy_impact first. Needs groupId.
• delete_scope: Delete an Access Scope. Needs groupId. Asks for confirmation.
• update_auto_messages: Save automated app messages. Full replace of the config from door_access_settings_read auto_messages. Queues a background re-evaluation of everyone at the facility; follow it with auto_messages_sweep_status. Needs config.
• preview_policy_migration: Preview moving to Access Policies. The Access Policies the facility's legacy rules would become, without saving, with sourceRevision and sourceFingerprint for commit_policy_migration.
• commit_policy_migration: Move to Access Policies. Saves the previewed policies so they decide access from now on. 409 access_policy_migration_stale when the rules or doors changed since the preview. Needs expectedRevision, sourceFingerprint. Asks for confirmation.

How a facility fills User Access automatically: from partner integrations (member-management systems), CCTV and Performance Hub staff. Use it to see the sync settings, why a member did or did not sync, and what a bulk delete of synced people would remove. Change sync with door_access_sync_write.

Actions:

• partners: Partner integrations. Each partner with enabled state, synced people count and its time-window mapping.
• config: Sync settings. Per source: partner (with per-partner timeWindowAccess mappings and freshness), cctv, staff (on by default; its role filter lives in Org Settings > Brands > Door access), appInvitations rules, conflictResolution and the schedule.
• log: Sync log. Recent outcomes, newest first, with the reason each member did or did not sync.
• bulk_delete_preview: Preview deleting synced people. How many partner-synced people door_access_sync_write bulk_delete would remove, a sample, and the confirmToken it needs. Changes nothing.

Changes how a facility syncs User Access from partner integrations, CCTV and Performance Hub staff, runs a sync now, and bulk-deletes partner-synced people. Read door_access_sync_read config first and keep unrelated settings.

Actions:

• update_config: Change sync settings. Merges your patch into the current settings. Turning staff sync off asks first. Needs config. May ask for confirmation.
• run: Sync now. Sweeps every enabled source (it also runs nightly) and returns processed, created, updated and skipped per source. Partner removals that look like a bad pull are held back as partner.removalGuardTripped; applying them with confirmMassRemoval asks first. May ask for confirmation.
• bulk_delete: Delete synced people. Soft-deletes the partner-synced people from bulk_delete_preview. 409 when they changed since. Needs confirmToken. Asks for confirmation.

The people who can sign in to the Door & Gate Access app at a facility (User Access): manual, partner-synced, CCTV and Performance Hub staff rows. Use it to find a userId, check whether and why someone can get in, or pick who to invite. Change people with door_access_users_write.

Actions:

• list: List people. Compact rows with hasAccess (an Access Policy, permanent grant or time window lets them in now or later), sync and app state. Use get for grants and time windows.
• get: Get a person. One row in full, including grants, admin timeWindowGrants, synced sourceTimeWindows and their freshness. Needs userId.
• effective_access: Explain a person's access. Per door: allowedNow, allowedVia or deniedReason, block and maintenance state, active and next time window, scopes and source freshness. Check this before replacing grants. Needs userId.
• people_config: Person types, statuses and tags. The distinct person types, membership statuses and tags at the facility, for building Access Policy audiences.
• invitation_preview: Preview app invitations. Who an invitation round would email, without sending: people with an email who have never used the app, by default only those with access who weren't invited yet. Returns counts, a sample and every userId for door_access_users_write send_invitation.

Adds, edits and removes the people who can use the Door & Gate Access app at a facility, and manages their grants, sync coupling, app sessions and invitations. Find userIds and check current access with door_access_users_read first. Staff rows (source staff) follow Performance Hub IAM: delete, decouple and recouple return 409 staff_row_managed.

Actions:

• create: Add a person. A manual row. sendInvite also emails the app invitation. 409 returns the existing row when the phone or email is already at the facility. Needs user.
• bulk_create: Import people. Up to 200 rows with per-row outcomes. Rows take the user fields plus accessEnabled and permanent grants; add time windows afterwards with set_time_window_grants. Emailing invitations asks first. Needs users. May ask for confirmation.
• update: Edit a person. Partial edit, including accessEnabled (their access switch), autoMessageSuppressed, a personal appMessage and timeWindowGrants. Needs userId, user.
• delete: Remove a person. Soft delete; they lose app access and their access logs are kept. Needs userId. Asks for confirmation.
• set_grants: Replace permanent grants. Replaces the permanent grants; time windows are untouched. Needs userId, grants. Asks for confirmation.
• set_time_window_grants: Replace admin time windows. Replaces only the admin-owned time-window grants; permanent grants and synced windows are untouched. [] clears them. Needs userId, timeWindowGrants. Asks for confirmation.
• decouple: Stop syncing a person. Freezes the row against partner and CCTV sync and clears its synced time windows, so admins control it by hand. Needs userId. Asks for confirmation.
• recouple: Resume syncing a person. Needs userId.
• logout: Sign a person out of the app. Revokes every app session matched by their phone or email; returns how many were revoked. Needs userId.
• resend_invite: Resend the app invitation. Emails one person the app invitation again; they need an email on file. Needs userId.
• send_invitation: Send app invitations. Emails the app invitation to up to 50 userIds from door_access_users_read invitation_preview; send longer lists in batches. People who vanished, lost their email or signed in since are skipped. Needs userIds. Asks for confirmation.