/statistic/entries: Get raw occupancy records for an account or a single location.
GET/statistic/entries
What
Returns one row per presence: a client sat at a location from from until to.
A row is written when the presence ends — when the client moves to another location,
signs off, disappears, or when the day rolls over (see Day boundaries below).
Presences shorter than 60 seconds are discarded as noise and never appear here.
The data is deliberately not pre-aggregated: nothing is summed into parent locations, and there is no per-hour or per-day rollup. You get the raw intervals and aggregate them the way your report needs. This also means a later change to the location tree applies retroactively — historical rows follow the tree as it is today.
| Field | Meaning |
|---|---|
locationId | The location the client occupied |
locationPath | Full path in the location tree, e.g. Building A/Floor 2/Desk 5 |
externalLocationId | Id in your partner system; empty in pure Shigoto operation |
clientId | Pseudonymous client key — see Counting people below |
deviceType | Which device types evidenced this presence, e.g. ["Monitor","Usb"] |
category | Derived from deviceType: location, environment, mixed or unknown |
from | Start of the presence |
to | End of the presence — and the moment the row was written |
currentUser | Number of people this row represents. Always 1 today |
Counting people
Always count COUNT(DISTINCT clientId), never the number of rows. One person can produce
several rows at the same moment: someone whose monitor identifies a desk and whose Wi-Fi
identifies the room appears once per location. Counting rows would count that person twice.
Note that clientId rotates once per day. Within a day it identifies a device reliably;
across several days COUNT(DISTINCT clientId) counts device-days, not devices. For longer
periods, count per day first and aggregate the daily figures afterwards.
Day boundaries
A presence never crosses midnight: running presences are cut at the day boundary and
continue as a new row. from and to of a row therefore always fall on the same day, so
grouping by either yields the same result. A machine left running overnight produces one
row per day rather than a single long one.
Occupancy over time
Rows are intervals, not samples. To get a curve, expand each row into two events — +1 at
from, -1 at to — order them by time and build a running total. For a fixed grid,
bucket by from instead.
Exporting periodically
For a recurring export (for example a nightly job feeding a dashboard) use changedSince
together with cursor, not from/to. Pass the largest to you received last run as
changedSince; you then get exactly the rows written since then. Follow nextCursor until
it comes back null — that marks the end of the result. This is gap-free and free of
duplicates even while new rows are being written.
Who
Account administrators of the account (and higher). A caller below tenant level always
receives their own account's data, regardless of the accountId passed.
Login
Login or API key (both allowed).
Request
Responses
- 200
- 400
- 404
OK
Bad Request
Not Found