> For the complete documentation index, see [llms.txt](https://docs.butlr.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.butlr.io/historical-occupancy/faqs.md).
# FAQs
Commonly Asked Questions about Reporting API v3
Why do I see different numbers between traffic_floor_occupancy/floor_occupancy , and traffic_room_occupancy/room_occupancy?
The difference between `traffic` and `occupancy` base metrics stems from the type of sensors used and how they calculate occupancy:
* **`traffic_floor_occupancy`** is calculated using traffic sensors at main floor entrances, tracking people as they enter and exit the floor.
* **`floor_occupancy`** aggregates counts from presence sensors that cover specific areas on the floor, providing a snapshot of occupancy only within those monitored areas.
#### Traffic Mode
In [**traffic mode**](https://docs.butlr.io/historical-occupancy/pages/tyUDwu57k07Re6pSyyJL#id-1.-traffic-mode), sensors track **entries and exits** at designated floor entrances to estimate occupancy. This mode effectively monitors overall movement trends but does not directly capture occupancy across all areas of the floor. Missing even a single entry or exit can introduce drift, causing compounding inaccuracies over time. To manage this, the occupancy count resets to zero at midnight daily.
#### Presence Mode
In [**presence mode**](https://docs.butlr.io/historical-occupancy/pages/tyUDwu57k07Re6pSyyJL#id-2.-presence-mode), sensors detect **activity within defined spaces** by counting individuals within their field of view. This gives a real-time snapshot of occupancy in areas covered by presence sensors, though it does not account for people outside these areas. Counts may also fluctuate slightly if individuals move between sensors within a short period (e.g., walking through multiple spaces within a minute).
#### Why Traffic and Presence Counts Differ
Due to these different methods, `traffic_floor_occupancy/floor_occupancy` and `traffic_room_occupancy/room_occupancy` counts will inherently vary:
* **Limited Presence Coverage**: Where presence sensors cover only part of a floor (e.g., 10%), traffic counts at main entrances will typically show higher occupancy.
* **High Coverage Floors**: With 80%+ coverage by presence sensors, counts tend to align more closely, though minor fluctuations and occasional missed entries/exits can still create discrepancies.
These differences mean that `traffic_floor_occupancy/floor_occupancy` and `traffic_room_occupancy/room_occupancy` will not match perfectly.
Why does a large query fail with 500 Internal server error and no errors body?
The response was larger than the **10 MB per-response limit**. Validation problems come back as `400` with an `errors` array, but a response over 10 MB is discarded by the API gateway in front of `api.butlr.io`, which replies with a bare `500` and `{ "message": "Internal server error" }`. This is an AWS platform limit and cannot be raised.
It typically shows up when the same query works for a short time range (for example one hour) but fails for a longer one (for example three days). Shorten the time range, narrow the spatial filter, use a coarser `window.every`, or request the result in pages with `paginate`. See [Query Limits](/historical-occupancy/reporting-api-overview/query-limits.md#maximum-response-size) for how to estimate response size, and [Pagination](/historical-occupancy/reporting-api-overview.md#pagination) for the request format.