Performance & limits

Service limits at a glance

Limit	Value
Per-query time limit	30 seconds — longer queries fail with HTTP 500
Max page size	limit clamped at 10,000 features
Edge cache	60 seconds per response
Total counts	No numberMatched in responses (count via WFS)
Server-side sorting	OGC API sortby is a no-op — use WFS sortBy
Writes	None — the API is read-only
CORS	Open (Access-Control-Allow-Origin: *)
Undocumented paths	Return 403

Scope your queries

The service is backed by a large database (~18.7M hotspot rows). Well-scoped queries are fast — sub-second to a few seconds; broad unscoped ones can be slow or time out.

• Combine a reasonable bbox, an observed_at time window, and/or active = true. A broad-area bbox with a large limit and no other filter is the main query shape that can exceed the 30-second limit and return HTTP 500.
• active = true and observed_at ranges are fast (indexed). Filtering by non-indexed attributes over large sets is slower.
• Prefer time windows over deep paging for bulk pulls — see Paging & bulk export.

Retries

Treat an HTTP 500 with a timeout message as retryable: narrow the query (smaller bbox, shorter time window, add active = true) and retry with backoff.

Caching & freshness

Responses are cached for ~60 seconds at the edge: identical requests within a minute are served from cache, and freshly ingested detections can lag by up to a minute on top of the ingestion cadence — see Data sources & update cadence.