#Performance tips

#Wide-date-range searches

POST /v1/{entity}/search automatically splits date ranges > 14 days into 7-day windows and fetches them in parallel. For very wide ranges (years), the overhead of many windows can slow things down.

• Prefer /aggregate if you only need counts or sums.
• Pass "autoWindow": false in the request body to disable windowing for a single query.
• Narrow the date range client-side — dashboards rarely need "all time" by default.

#Dashboard warmup

If your app issues 5 sequential requests on load (/v1/users, /v1/statuses ×3, /v1/leads/search), consider the POST /v1/batch endpoint to pack the first four into a single HTTP round-trip. The batch costs 1 rate-limit unit regardless of sub-call count (up to 50).

#Freshness vs. speed

/v1/users and /v1/statuses responses are cached for 60 s / 5 min respectively. If your feature needs guaranteed-fresh data, send Cache-Control: no-cache.