Alert EnterpriseWiki

Brivo

Brivo·AE_HSc_BrivoConnectorGuide

PACSactiveBrivo Access REST API v11.21 (August 2024)
Transports
rest
Direction
bidirectional
Authentication
OAuth 2.0 password grant +1
Topology
cloud

Overview

The Brivo connector integrates AlertEnterprise Guardian with Brivo Access (formerly Brivo OnAir) — Brivo's cloud-native physical access control system. Unlike most PACS in the AE catalog, Brivo's controller stack ("Brivo Access Control Manager") runs entirely in Brivo's cloud; the customer operates only the readers and door hardware on-prem.

The connector ships as ALNTBrivoConnector-5.0-SNAPSHOT.jar and deploys with the AE application build. Once configured, the Alert Connector Framework (ACF) drives the Brivo Connector module over HTTP(S), which in turn calls the Brivo REST API Service in Brivo's cloud — that service fans out to Brivo's Access Control Manager. All four AE→Brivo flows (Create/Update/Delete User, Modify Roles, Add/Delete Badge) plus full + incremental reconciliation run through this path.

Authentication is layered: an OAuth 2.0 password-grant token from https://auth.brivo.com/oauth/token is obtained at session start, scoped by Client ID + Client Secret + API Key, and used for all subsequent REST calls. SSL certificate import into the Java keystore is mandatory; the connector will not communicate over plaintext.

Architecture

Composed from this connector's actors + edges. Trust zones are color-coded; trust crossings render as thicker lines.

Composing diagram — running ELK layout5 actors · 4 edges

Authentication

2 methods supported

OAuth 2.0 password grant
oauth2-password

Brivo's REST API requires an OAuth 2.0 access token obtained via the password grant flow. The token URL is https://auth.brivo.com/oauth/token?grant_type=password. The connector posts the configured userId + password along with clientId + clientSecret. The access token is then sent on subsequent REST calls.

Credential storage
Encrypted in AE connector configuration (System Parameters tab).
Brivo API Key
api-key

In addition to OAuth, Brivo requires an api_key System Parameter — issued per Brivo customer account — which is included on every REST request. The combination of OAuth token + API key authenticates *both* the AE tenant and the Brivo organization.

Credential storage
Encrypted in AE connector configuration (System Parameters tab).

Endpoints

1 endpoint exercised by the connector

MethodPathDescriptionCategory
POSThttps://auth.brivo.com/oauth/token?grant_type=passwordOAuth 2.0 password-grant token acquisition.auth

Prerequisites

Everything that must be in place for this connector to work, with the owner who's responsible.

Brivo organization with API access

customer

An active Brivo Access subscription with API access enabled. The customer must obtain Client ID, Client Secret, and API Key from Brivo (provided as part of the Brivo subscription per p7 of the guide).

API user account in Brivo

customer

A dedicated Brivo user with API access and provisioning privileges. This account's userId and password are used in the OAuth password grant flow.

SSL certificate trust

ae

Brivo's REST endpoints serve TLS — the customer's AE installation must trust the Brivo certificate chain. The guide documents the manual keytool -importcert procedure for importing the Brivo certificate into the JVM cacerts keystore at /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts. Both the Job and API services must be restarted after import.

Image staging directory

ae

A writable filesystem path on the AE host, configured as the IMAGE_LOCATION system parameter. Cardholder photos are written here temporarily during provisioning before being uploaded to Brivo.

Known limitations

Documented constraints to set customer expectations before deployment.

OAuth password grant is the only supported flow

important

The connector authenticates with OAuth 2.0 password grant — a flow that the IETF has deprecated for non-first-party clients (RFC 6749 § 4.3 was removed in OAuth 2.1 drafts). This means the AE installation effectively stores the Brivo administrative user's password in connector config. Customers with policies against storing service-account passwords in third-party apps must work with Brivo to obtain a dedicated API user with a long-lived rotated credential.

Image upload requires local staging

informational

Cardholder photos cannot stream directly from AE to Brivo; they are first written to the IMAGE_LOCATION filesystem path, then uploaded. Ensure this directory is cleaned up by a separate job to avoid disk-fill incidents.

Data fields

12 fields mapped between AE Guardian and the vendor system.

AE fieldVendor fieldDescriptionDirectionRequired
userIdUserIdPrimary user identifier in Brivo.bidirectionalyes
firstNamefirstNameCardholder first name.bidirectionalyes
lastNamelastNameCardholder last name.bidirectionalyes
middleNameMiddleNamebidirectionalno
emailemailbidirectionalno
photoPhotoCardholder photo, provisioned via the `IMAGE_LOCATION` system parameter staging directory.outboundno
badgeIdcard_numberCard number portion of a Brivo credential (Standard 26 Bit format).bidirectionalno
badgekeycredentialIdBrivo's internal credential record identifier.bidirectionalno
validFromeffectiveFromBadge activation timestamp.outboundno
validToeffectiveToBadge expiration timestamp.outboundno
readerPINPINPIN paired with the cardholder credential.outboundno
roleSourceIdrole.idBrivo role identifier for role assignment.bidirectionalno

PACS specifics

Cardholder model

Brivo represents a cardholder as a User record with one or more associated User Badge records. Each Badge carries credentialId, card_number, facility_code, effectiveFrom, effectiveTo, and a credentialFormatName (e.g., "Standard 26 Bit"). Roles are assigned via UserRoleData records linking a User to a Brivo role.id.

Access rights model

Access is granted by assigning a User to one or more Brivo Roles (UserRoleData mappings). The connector supports Provisioning (create / update / delete role assignments) and Reconciliation (full + incremental) of role-to-user mappings.

Multi-tenancy

Each Brivo organization is a separate tenant in Brivo's cloud. The connector authenticates per-organization via Client ID + Client Secret + API Key; one AE→Brivo connector instance corresponds to one Brivo organization.

Topology + Events
Topology
cloud
Event model
polling
Anti-passback
unknown
Holiday schedules
unknown
Card formats
Standard 26 Bit
Source materials
  • src/connectors/brivo/source.pdf Full connector guide — 17 pages, updated 2025-05-19
  • src/connectors/brivo/source.pdf p5 — Supported Version
  • src/connectors/brivo/source.pdf p5 — Provisioning Capabilities
  • src/connectors/brivo/source.pdf p7 — Connector Architecture diagram
Verifying access
Desktop only

The AE Mobile Wiki needs a bigger screen.

The diagrams, comparisons, and animated flows aren't built for phones. Open this link on your laptop or desktop browser and you'll see the full reference.

wiki.alertenterprise.app

Same Google sign-in as the AE App Hub — you'll be in once you open it on a larger screen.