Brivo Physical Security custom web services connector?

SailPoint Human Fabric (SHF) SHF Discussion and Questions
, , ,
1

Just checking with the community here before going too far down this rabbit hole - has anyone built a Custom Web Services Connector to Brivo? Willing to share details of the configuration?

Note: this is Brivo, the physical security platform to badge into office spaces, not to be confused with Brevo, the marketing tools platform.

2

Hi @sup3rmark,

I haven’t seen a Brivo WS config shared here yet, but I went through their Access API docs and a few things will shape the design:

  • Auth: OAuth2 only
  • Token lifetime: 300 s, so watch long aggregations
  • API calls: every call needs api-key + Authorization: bearer <token>
  • Paging: offset/pageSize, max 100
  • etc…

Other than that, it should be pretty straightforward. You’ve probably already looked at it, but Brivo publishes an LLM-friendly index at apidocs.brivo.com/llms.txt that points to per-tag OpenAPI files. That’s the quickest way to get exact paths and schemas.

Useful links:

Hope this helps! Curious to see if anyone here has already built one. :t_rex:

3

Hi @sup3rmark,

I recently completed a Brivo integration with SailPoint ISC, and we’re preparing for production deployment. I can’t share our exact configuration, since in our final setup Brivo is exposed through our own API Gateway (client credentials mode). But here’s what I learned along the way, which should help you get started.

Brivo user model

Brivo has two distinct user types, each with its own set of APIs:

  • Administrators
  • Users

Full API reference: Brivo API Documentation

Authentication

Brivo uses a 3-legged authentication model that combines the OAuth 2.0 Password grant with an API key. You’ll need three things:

  1. An API key: create a Brivo developer account and generate one there.
  2. Client credentials: generate a client ID and client secret in your Brivo tenant from the market place.
  3. An administrator account: a username and password with the appropriate rights.

The Brivo documentation walks through the full flow.

Connector setup

Before moving everything behind our API Gateway, I had authentication working directly with the ISC Web Services SaaS Connector:

  • Authentication type: OAuth 2.0 – Password grant
  • On every HTTP operation: add the API key as a request header

That setup worked well and is a good starting point.

What works

Standard user lifecycle operations (create, update, suspend) work fine. Group management wasn’t in our scope, but I did see group-related endpoints in the API, so it should be doable.

Aggregation and API limits

For account aggregation, I initially used a parent/child aggregation setup to includes groups, but ran into delays and token expiration issues during longer runs.

Keep an eye on API quotas too:

  • The API key generated through the Brivo developer portal is limited to 25,000 API calls per month, which runs out quickly with parent/child aggregation.
  • For production, you need to request a dedicated API key from Brivo support.

Limitations to be aware of

Administrators

  • Administrators can’t be disabled through the API.
  • The phone number is mandatory when creating an administrator in the UI, but we couldn’t find the matching field in the API. We’ve raised this with Brivo support.

Custom attributes of Users

  • Each user-level custom attribute has its own update endpoint. If you manage many custom attributes, you’ll need either a custom rule or one HTTP operation per attribute. We left this out of our initial phase.

Thanks!