# Brivo Physical Security custom web services connector? **URL:** \ **Category:** SHF Discussion and Questions\ **Tags:** webservice-connector, identity-security-cloud, provisioning, connectors\ **Created:** [October 15, 2026, 9:20pm UTC](https://developer.sailpoint.com/discuss/t/brivo-physical-security-custom-web-services-connector/225687 "2026-10-15T21:20:08Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![sup3rmark](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/sup3rmark/32/36229_2.png) [@sup3rmark](https://developer.sailpoint.com/discuss/u/sup3rmark)\ **Post date:** [October 15, 2026, 9:20pm UTC](https://developer.sailpoint.com/discuss/t/brivo-physical-security-custom-web-services-connector/225687/1 "2026-10-15T21:20:08Z")
Just checking with the community here before going too far down this rabbit hole - has anyone built a Custom Web Services Connector to [Brivo](https://www.brivo.com/)? 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. ---
**Author:** ![sbisson](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/sbisson/32/6749_2.png) [@sbisson](https://developer.sailpoint.com/discuss/u/sbisson)\ **Post date:** [October 16, 2026, 1:24am UTC](https://developer.sailpoint.com/discuss/t/brivo-physical-security-custom-web-services-connector/225687/2 "2026-10-16T01:24:32Z")
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 ` - **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](https://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: - [https://apidocs.brivo.com/](https://apidocs.brivo.com/) - [API conventions: auth, paging, errors](https://apidocs.brivo.com/access/api-overview.md) - [Developer portal: API keys](https://developer.brivo.com) - [API tiers and enablement process (Seam’s guide)](https://docs.seam.co/latest/device-and-system-integration-guides/brivo-access/brivo-access-setup-guide) Hope this helps! Curious to see if anyone here has already built one. 🦖 ---
**Author:** ![baoussounda](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/baoussounda/32/13095_2.png) [@baoussounda](https://developer.sailpoint.com/discuss/u/baoussounda)\ **Post date:** [October 16, 2026, 7:20am UTC](https://developer.sailpoint.com/discuss/t/brivo-physical-security-custom-web-services-connector/225687/3 "2026-10-16T07:20:41Z")
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](https://accessapi.brivo.com/) ### 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!