Brivo Access API
Check the Brivo API workflow, access requirements and supported resources. Map identities, credentials, events and permissions to the needs of your integration.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Public Brivo Access documentation and programme material reviewed on 25 August 2026; customer editions, production approval, service to service flow, quotas, endpoint schemas, devices, credentials, and feature licences require the developer portal and authorised account.
On this page
Overview#
Vendor APIs / Access and identity / Brivo
Brivo now publishes separate Access and Video developer documentation. This page covers the Brivo Access API, sites, users, credentials, groups, doors, events and associated access control operations, not the Brivo/Eagle Eye video API.
Documented scope and access#
| Element | Publicly documented model | Boundary |
|---|---|---|
| Documentation | Public Access API reference, auth guides and endpoint material | Documentation host is not the runtime API |
| Developer portal | Registers applications and requests production API keys | Portal approval and application/customer configuration required |
| Three legged application | OAuth 2.0 Authorisation Code plus Brivo application credentials/API key | Customer administrator/user authorises access; exact redirect URI registered per app |
| Service integration | Alternative server to server flow available by contacting API support | Do not invent or repurpose a password flow; obtain the approved contract |
| Brivo Access edition | API integrations depend on commercial edition/addon | Product sheet observed API integrations as an addon in Standard and included in higher editions; recheck at purchase time |
The official documentation router generated 5 August 2026 says all documentation files are public and clearly separates Access from Video. Follow only the Access branch for access control work.
Authentication and application design#
Brivo’s official Access integration guidance uses an API key plus OAuth client credentials and the Authorisation Code flow for customer delegated access. Protect all confidential material in a backend. Validate state, exact redirect URI and TLS; never expose client secret or API key in a browser bundle or mobile binary.
The official example prompt page explicitly labels its local Vite/loopback patterns as development harnesses, not production architecture. It warns about localhost proxy relay, browser token theft, development only HTTP redirects, missing server side revocation and sensitive raw errors. A production application should use a hardened backend, secure HTTP only sessions, per request authorisation and HTTPS redirects.
Create a distinct application/API key per integration and customer model as Brivo requires. Use a dedicated service administrator/role where the current programme guide permits, so audit and permissions aren't tied to a person who may leave. Rotate secrets and revoke unused applications.
Domain and state model#
Keep these workflows independent:
- user/person creation and authoritative identity matching;
- physical and mobile credential issue, invitation, assignment and revoke;
- group/access assignment and schedule/effective time policy;
- site, panel, reader and door inventory/status;
- access events and audit retrieval;
- unlock and emergency scenario operations.
Cache lookup data only with revision/expiry. Use stable IDs rather than names for groups, formats, sites or doors. Validate bulk input completely before mutation and design compensation for a partial user/credential/group transaction.
An invitation or credential created response doesn't prove mobile delivery or controller propagation. An unlock response doesn't prove lock state or passage. Preserve controller/door event evidence and reconcile.
Pagination, limits, and events#
Use the current Access reference’s endpoint specific pagination and filters. A numeric global rate limit was not independently established from the reviewed public overview, so this page makes none. Implement bounded concurrency, 429/transient backoff and customer visible quota diagnostics, then record the quota supplied by Brivo for the application.
For events, store stable event ID, site/door, subject identifier, source and ingest time, and pagination/checkpoint state. Minimize names, e mail, card values and other personal data. Reconcile gaps rather than treating a polling window as complete by assumption.
High impact safety boundary#
Door unlock and emergency scenario operations need independent explicit privileges, allowlisted targets, operator confirmation, reason, idempotency/uncertain outcome behaviour and immutable audit. Never expose them through a generic proxy or execute them as part of API exploration. Preserve fire/egress and local controller authority.
Primary sources#
- Brivo API Documentation and Resources, official Access/Video separation and portal routes.
- Brivo documentation router, generated public documentation map and runtime host warning.
- Official Access development prompts and production warnings, auth/application requirements and explicit dev harness limitations.
- Brivo Technology Partner programme overview, OAuth and API key integration guidance; confirm current terms.
- Brivo Access editions, mutable API integration commercial boundary.