Skip to content
DeepfireDeepfire Docs
Esc
↑↓navigate↵open⌘Jpreview
On this page

Performance & limits

Service limits at a glance — query timeout, page size, concurrency, caching — and how to scope queries so they stay fast.

Service limits at a glance

Limit Value
Authentication Required on every request (bearer token)
API keys per account 5
Per-query time limit 30 seconds — longer queries fail with HTTP 500
Max page size limit clamped at 10,000 features
Concurrent requests Shared cap across all callers — excess gets 503 + Retry-After
Response cache 60 seconds, private to your client
Total counts No numberMatched in responses — page until a short page (paging)
Server-side sorting None — sortby is accepted but ignored; sort client-side
Writes None on the OGC API; fire spread runs are queued via POST
Fire spread runs 2 in flight per API client, 1–24 h, ≤50 ensemble members, 5–50 km domain (details)
Fire spread tuning Every engine parameter optional; defaults and ranges under Model parameters
CORS Open (Access-Control-Allow-Origin: *)

Scope your queries

The service is backed by a large database (full detection history since January 2025). 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.

A 503 is retryable too — honor Retry-After. A 401 is not: re-run the token exchange rather than retrying the same request.

Caching & freshness

Responses carry Cache-Control: private, max-age=60. Because they are authenticated they are never held in a shared cache, but your own HTTP client may reuse one for up to a minute. Freshly ingested detections can therefore lag by up to a minute on top of ingestion itself.

Was this page helpful?