Pushing data in

You already count or measure something Omaya cannot see itself — a video conferencing system's person count, a badge system's in-building tally, another sensor cloud. Send it in and it behaves like any other reading.

People counts from your own systems

POST /api/v1/occupancy/readings

Each reading names a source_id, a zone_uid (or a venue_uid for a building-wide source), a count, and when it was captured. Up to 200 readings per call, and a text/csv body is accepted as well as JSON — which is usually what a badge-system export already is.

POST /api/v1/occupancy/readings
X-Tenant-ID: yourorg
X-Api-Key: <your key>
Content-Type: application/json

{"readings": [
  {"source_id": "rallybar-mr1", "zone_uid": "…", "count": 4, "captured_at": "…"}
]}

What arrives is stored like a decoded sensor reading, so with no further setup it feeds Right Now, Space Utilisation, the history endpoints, the occupancy webhook, the assistant and utilisation rules. The zone's source becomes external, so anyone reading the number can see where it came from.

Send a level, not a total

count is how many people are there now, not how many have entered. A badge system should send its net in-building count, not the turnstile tally. Sending entries makes a room that hosted forty people over a day look like it holds forty people.

Give each counting device or system a stable source_id and keep it stable — 1 to 13 characters, lowercase letters, digits and hyphens. It is how Omaya tells your two conference rooms apart.

Sensor data over MQTT

Gateways deliver BLE and LoRaWAN traffic over MQTT, and that path is open to your own devices too. It is the right route when you have real sensors rather than a system with an API — a gateway you already own, a fleet of devices on your own broker.

If the device model is one Omaya knows, that is all there is to it. If it is not, teach it the device — the onboarding wizard builds a decoder from the device's own live packets, and the decoder is then yours.

Choosing between them

You have	Send it as
A system that knows how many people are in a room	A people count, over the API
A badge or access-control system	A venue-wide count, over the API — the net figure
Doorway counters on every entrance of a floor	Nothing — tick "every way in and out is counted" on the venue and Omaya nets them
Physical sensors of your own	MQTT, decoded like any other device
A product on the connectors list	Neither — configure the connector

Checking it landed

Right Now picks up an external count within ten minutes. The zone's source badge should read external, and the count should match what you sent.

If it does not: check the response body from the call itself — rejected readings come back individually with a reason, rather than the whole call failing. The usual causes are a zone_uid from a different organisation, a count outside the accepted range, or a captured_at far enough in the past that it lands in a window nobody is looking at.