Occupancy data is only as useful as the system it informs. Counts that live inside a vendor dashboard are counts that produce a screenshot, not a schedule change. The Occivar integrations layer is designed around the assumption that the building, the operations team and the data team already run a stack, and the platform's job is to fit that stack, not replace it.
01 · WHAT WE INTEGRATE WITH BY DEFAULTWhat we integrate with by default
Four classes of integration ship in the base platform:
- Building Management Systems. Direct BACnet/IP and Modbus output, plus REST adapters for the major cloud BMS platforms. Density and recommended schedules flow into the BMS without an operator having to retype them.
- Operations channels. Slack, Microsoft Teams, SMS, email and PagerDuty webhooks. Alerts route per the platform's routing graph into whichever channel the on-call attendant lives in.
- Data warehouses. Native push into Snowflake, BigQuery and S3 (Parquet). Counts, dwell distributions, alert history and methodology metadata are all queryable from the data team's existing tools.
- REST and webhook fallback. Anything not covered above is reachable from a signed REST endpoint and an outbound webhook, with a JSON schema that mirrors the dashboard contract.
What does not integrate, ever: the raw video. There is no video to integrate. The architecture means the integration layer only ever carries the counts, the densities, the dwell figures and the threshold metadata.
02 · THE PATTERN WE EXPECTThe pattern we expect
The pattern we expect on a production deployment runs roughly like this:
- BMS reads recommended schedules from the platform's right-sizing endpoint and applies them to HVAC and lighting overnight. The deviation between recommended and actual schedule becomes a metric the property team tracks.
- Slack receives threshold alerts routed by the platform's alerts layer. Ack-required pushes go to the attendant on the floor; informational copies go to the ops channel.
- Snowflake receives the count and density stream as Parquet, partitioned by zone and hour. The data team joins it to building-management-system telemetry, weather, and the booking system.
- REST consumers subscribe to whatever specific signal a third-party tool needs: a digital sign system polling current density, an evacuation-runbook trigger listening for a sustained threshold crossing.
That mix produces a building that uses its occupancy data inside the existing workflows, not next to them.
03 · AUTHENTICATION, SIGNING AND THE BORING PARTSAuthentication, signing and the boring parts
Every integration channel is authenticated by default. Webhooks are signed. REST endpoints use rotating tokens with scoped permissions. The data warehouse loaders run as a service identity with least-privilege grants. The audit log records every read and every write.
None of this is novel. It is just the boring infrastructure choices that make integrations survive a security review.
04 · HOW THE INTEGRATIONS LAYER FITS THE RESTHow the integrations layer fits the rest
Integrations consume what occupancy analytics, alerts and reports produce, and route the right signal into the right system. The architecture means none of the integrated systems ever see anything identifying, because no identifying data was ever produced.
If your last occupancy platform stopped at the dashboard, the integration conversation is the one worth having next.