Reference · built on requestConnectorAccess control & video

Verkada

Doors, access events, cameras, alarms, sensors, and Guest visits from Verkada Command, with door release and credential actions.

About

Verkada sells cloud-managed cameras, door controllers, alarm panels, environmental sensors, intercoms, and Guest visitor kiosks, all administered in Command. One REST API spans them, with regional hosts for the United States, Ohio, Europe, Australia, and GovCloud. Webhooks configured in Command push access, alarm, credential, and license-plate events.

Through Fibric, an operator watches door and sensor events, pulls a thumbnail or footage link for the moment in question, and proposes a door release, a credential change, or an access scenario. You approve; the request runs once and is logged.

This is a reference listing. It documents what Fibric would read from Verkada and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Access events through GET /events/v1/access, such as door_forced_open, door_held_open, door_tailgating, and door_remote_unlock_accepted
  • Unified camera, access, and sensor events in one time-ordered feed through the v2 Get Events endpoint
  • Doors, sites, access levels, schedule events, and door exception calendars
  • Access users with cards, entry codes, BLE, face credentials, license plates, and start and end dates
  • Camera data, thumbnails, and footage links, plus occupancy trends and license plates seen by LPR cameras
  • Sensor readings and sensor alerts over a time range, and alarm site devices
  • Guest sites, hosts, visits, guest events, approved lists, and audit logs

Proposed actions

  • Target capability: propose a door release through POST /access/v1/door/admin_unlock, or as a named user through the user_unlock endpoint
  • Target capability: propose activating or deactivating a card, entry code, BLE, or remote_unlock for an access user
  • Target capability: propose an end date for a departing user, or adding and removing them from an access group
  • Target capability: propose activating or releasing an access scenario such as a lockdown
  • Target capability: propose a Guest event that pre-registers visitors with a host, guest type, and time window

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Act on a forced or held door

    A door_forced_open or door_held_open webhook arrives with door_info and a timestamp. The operator fetches the camera thumbnail for that moment and proposes an alert with the still attached.

    With Door Held Open, Access Anomaly

  • Catch tailgating for review

    door_tailgating events are grouped by door and shift. The operator proposes the clips to review and drafts the reminder to the people involved.

    With Tailgate Review

  • Keep cameras and doors reporting

    Alerts for camera offline and camera online, plus door_low_battery and door_critical_battery events, feed a health list. The operator proposes a work order for each device still down.

    With Camera Health

  • Pre-register tomorrow's visitors

    From a calendar or ticket, the operator proposes a Guest event with host, guest type, invitees, and start and end times so the kiosk expects them.

    With Visitor Pre-Registration

Requirements

  • A Verkada organization with an API key acquired from Command, and an Organization Admin to add webhooks under Organization Settings > Verkada API
  • An API key scoped to each product the operator will touch, for example Read/Write on Access to release doors
  • The regional base URL for your organization; a credential works only in the region where the org was created
  • A public HTTPS endpoint that answers 2xx within 2 seconds for webhooks, with the shared secret to verify Verkada-Signature
Authentication
An API key created in Command, exchanged at POST /token for a 30-minute API token sent in the x-verkada-auth header; the token inherits the key's per-product Read or Read/Write permissions.

Limits

  • 300 requests per minute per organization across all endpoints, enforced in 5-second windows with HTTP 429 and a 5-second cooldown
  • API tokens live 30 minutes and cannot be refreshed; a new token is minted from the API key
  • Access event pages return at most 200 items; the default window is the last hour
  • A failed webhook delivery is retried only once

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Verkada ↗

Questions and answers

How do I check a Verkada webhook signature?
Each delivery carries a Verkada-Signature header. Compute HMAC-SHA256 with your shared secret over the JSON body, a pipe character, and the timestamp from the header, then compare in constant time. Verkada's sample checks the timestamp is within 60 seconds.
What is the rate limit?
300 requests per minute per organization across all endpoints, measured in 5-second intervals. Exceeding it returns HTTP 429 and a 5-second cooldown. Limits are per organization, not per key, and Verkada may adjust them per endpoint on request through support.
Can an API call open a door?
Yes. POST /access/v1/door/admin_unlock with a door_id opens it irrespective of any user's door privileges and returns the unlock_duration. The user variant opens the door as a specific user_id or external_id, subject to that user's access.
Ask about Verkada

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.