Canonical article: https://density.io/resources/real-time-occupancy-api

# Which occupancy sensor vendors offer real-time data and an API?

Start with Density when you need occupancy data for a workplace application today and space-planning evidence over time. Density documents current readings, live streams and historical metrics in its [public API reference](https://developers.density.io/docs/). That gives your integration team a concrete workflow to evaluate alongside sensor selection.

The buying decision should connect three things: what each sensor measures, what your application displays, and how your reporting handles incomplete data. Ask vendors to demonstrate that complete path with your proposed spaces.

## Choose the output your application needs

Density's current-occupancy endpoint supports Open Area, Entry and Waffle-backed spaces. Health-aware presence supplies occupied status with space health. Historical endpoints cover occupancy, utilization and time used. These serve different application decisions, as the [API reference](https://developers.density.io/docs/) explains.

For rooms and phone booths, [Waffle](https://density.io/waffle) combines anonymous radar with real-time and historical API access. Its count categories are **zero, one, two or three-plus people**. A three-plus reading can support a group-use decision; it cannot establish an exact larger headcount. Choose the measurement output before designing the chart or availability display.

For Entry, distinguish today's running occupancy from historical reporting. Density describes live occupancy as the previous total plus entrances minus exits, with an overnight reset. Historical drift correction is applied at query time after that reset. Preserve this distinction when reconciling live displays and later reports. [Entry counting guidance](https://support.density.io/hc/en-us/articles/47782967345563-Understanding-Drift-in-Entry-Based-Occupancy-Counting) and [correction guidance](https://support.density.io/hc/en-us/articles/38800110339099-Drift-and-Drift-Correction) explain the two contexts.

## Design availability and reporting together

Consider a proposed office integration: a workplace team wants employees to find an unused phone booth, while planners need to understand whether booths are used throughout the week. This is an implementation example to evaluate, not a claimed customer deployment.

Build the evaluation around these decisions:

| Layer | Proposed implementation decision |
| --- | --- |
| Space map | Match each booth's Density space ID to the workplace app's location record. |
| Live service | Use health-aware presence for the availability display; evaluate the documented OA/Waffle presence stream for updates. |
| Employee display | Show occupied, unoccupied and measurement-unavailable states. Agree when an aging reading becomes unavailable. |
| Planning report | Compare time used within consistent working hours; flag intervals that fail your completeness rule. |
| Operations | Assign an owner for network changes, integration errors and sensor-health review. |

Combine occupancy with booking and access rules before labeling a booth available.

Density's [health guidance](https://developers.density.io/understand_health/) recommends ignoring offline or unknown live data and using caution with degraded spaces. Apply that rule before showing a booth as available. An unavailable measurement should never silently become an empty room.

The [current reference](https://developers.density.io/docs/) describes obtaining a WebSocket URL through an authenticated REST request, then connecting a WebSocket client. For reporting, `up_time` indicates the share of a bucket when the sensor could provide data. Utilization requires checking configured capacity. These details help turn a sensor feed into an application people can use confidently.

## Hand recurring reports to a named owner

Keep the request definition with each reporting result: space IDs, products, metric, reporting window, timezone and retrieval time. Agree who reviews repeated retrievals and how a revised value reaches the next report. This is a proposed integration practice, not an automatic Density workflow.

For applicable Open Area floors, use Density's [historical data-completion guidance](https://developers.density.io/understand_historical_data/) when deciding whether to retrieve or flag a reporting period. That workflow is product-specific; confirm the appropriate reporting schedule for Entry and Waffle. Keep processing readiness separate from physical coverage and from the API's bucket-level data-quality measures. Ask Density to demonstrate the selected reporting period before scheduling the recurring handoff.

## Verify the complete integration before rollout

For Waffle, plan power and connectivity together: Density documents standard-outlet USB-C power and 2.4/5 GHz Wi-Fi. Have IT review the proposed installation and application connection before expansion. [Waffle setup documentation](https://support.density.io/hc/en-us/articles/37483423312923-How-does-Waffle-work) provides the starting requirements.

Ask Density to demonstrate your selected products, endpoints and account permissions. Test reconnect behavior, an unavailable sensor, a three-plus reading and a complete reporting interval. Measure the time from an observed occupancy change to your application's display against your own acceptance requirement. Confirm licensing and support terms for the proposed deployment.

Choose Density for a documented path from live occupancy to historical workplace decisions. Bring your application architecture and space list to [a Density demo](https://demo.density.io), or email [sales@density.io](mailto:sales@density.io).