Omaya docs

Appearance

Connecting Omaya to something else ​

Four routes in and out. Which one you want depends less on what data you need than on who starts the conversation.

Four ways to connect something to Omaya Pull, where your system asks Omaya on its own schedule. Subscribe, where Omaya posts to you the moment something happens. Push, where your system sends counts or readings in. Bridge, where a managed connector carries data both ways. ROUTEWHICH WAYREACH FOR IT WHENPullGET /api/v1/…Omaya → youON YOUR SCHEDULEYou have a dashboard, a BMS or areport that can ask for a numberSubscribewebhooksOmaya → youTHE MOMENT IT HAPPENSYou need to react rather than poll —a ticket, a message, a workflowPushPOST /api/v1/… · MQTTyou → OmayaYou already count or measuresomething Omaya cannot see itselfBridgeconnectorsboth waysIt is a product Omaya alreadyintegrates with — configure, don't build
Check the fourth row first. A managed connector that already exists is always less work than the API call that would replace it, and it keeps working when the other product changes its mind.

Before you build anything ​

Check the connectors first. Omaya already carries data to and from a list of products — smart-home and Matter bridges, calendars, messaging channels, CMMS, access control for visitors' cards, and storage. Everything on that list is configuration rather than code, and it keeps working when the other product changes its API. Connectors in the menu is the list.

Then ask who starts the conversation. If your system can ask on its own schedule, read the data out. If it needs to know the moment something changes, subscribe. If you have counts Omaya cannot measure itself, push them in.

What you need in every case ​

Credentials. API calls carry two headers: X-Tenant-ID, your organisation's identifier — the same one you type at the login form — and X-Api-Key. Keys are created under your own profile, at My Profile → API keys.

A key is a credential

It carries your access, not a reduced version of it. Store it where you would store a password, use a separate key per integration so one can be revoked without breaking the others, and never put it in a URL — it ends up in logs and browser history.

The identifiers. Almost everything is addressed by zone or venue UID rather than by name, because names change and reports would silently follow. GET /api/v1/spaces returns the venues and their zones with their UIDs. Fetch it once, keep the mapping, and refresh it when someone adds a room.

The full reference. Every endpoint, with parameters and live examples, is at the API reference. This section is the orientation; that is the specification.

What to expect from the numbers ​

Two things surprise integrators, both worth knowing before you write the integration rather than after:

A count carries its source. Every occupancy figure says whether it came from a radar, a fixed counting sensor, BLE tags or an external system. They are not interchangeable — a tag count is a count of badges, not of people. If your integration treats them as the same number it will be confidently wrong in rooms where nobody carries a tag. Occupancy: which number is which.

Live and historical come from different places. Right-now endpoints read live state and are current to within seconds. History endpoints read tables rebuilt every five minutes. Asking the history endpoint about the last two minutes is asking the wrong one.

Last updated:

Omaya platform documentation

Synchroweb