Status & Support

Diagnose before you escalate

Almost every reported failure is one of five things, and each has a distinguishable signature:

Symptom	Likely cause	Where to look
401 unauthorized on a call that worked yesterday	Key rotated, disabled, or the header is missing on one code path	Authentication
402 insufficient_balance	Balance below the reservation for this submission	Account & balance
A single request returns 200 but nothing was charged	The whole combo failed; HTTP status is not the outcome	Billing & refunds
The same request succeeds and fails in alternation	Rate limiting, or an Idempotency-Key being reused across different payloads	Rate limits, Idempotency
A bulk task sits in processing and last_progress_at stops moving	A genuinely stuck task, not a slow one	Task status

The last_progress_at case is worth stating plainly: elapsed time is not the failure signal, a stalled timestamp is. A 500,000-row task can legitimately run for a long while. A task whose last_progress_at has not moved is a task to escalate.

What to include in a support request

Every field below is returned by the API, which means including them costs you nothing and saves a round trip:

Include	Where it comes from
request_id	Every realtime response, including failures that returned a body
task_id	Every bulk submission and every task-status response
api_key_id	GET /v1/api-key — identifies the key without exposing it
The exact HTTP status and response body	Your own logs; the code field in particular
A UTC timestamp with seconds	Your own logs
The request you sent, with the key redacted	Your own code

Never paste an API key into a support request. api_key_id identifies the key, and the key itself grants access to your balance.

Incident communication

Account-level notices — planned maintenance, degraded capacity — appear in the Console, which is also where balance and records live. The API surfaces the same conditions to your integration directly, as error codes rather than as prose:

Code	What it means for a running integration
detection_capacity_unavailable	No capacity right now. Back off and retry; nothing was charged.
realtime_route_unavailable	No realtime route available. Back off and retry.
realtime_rate_limiter_unavailable	The limiter itself is down, so admission cannot be decided. Retry later.
realtime_fact_cache_unavailable	A realtime dependency is down. Retry later.

These are 503s and they are all in the “wait, then retry” group — see Error codes for the full grouping, including which failures are safe to retry with the same Idempotency-Key.

Availability targets and paid support tiers

Contractual availability, credited-service terms and support response targets are defined per agreement and are not restated here, because they differ by plan and a generic figure on a documentation page would be wrong for most readers. Your agreement is the authoritative source; ask your account contact if you need it in writing.

Where the platform stands today

Two operational facts are verifiable from outside and are worth knowing before you file an incident:

• The API is served behind Cloudflare, so the network path and TLS termination are operated by Cloudflare rather than on a single origin host.
• Every response carries X-RateLimit-Remaining, so a client that logs response headers can distinguish “throttled by my own limit” from “the service is down” without asking anyone. The general and detection groups also carry X-RateLimit-Limit on every response; realtime does not, because it spends a token bucket rather than a fixed per-minute ceiling.

Next

• Error codes — the retry groups, which is the fastest triage table
• Security — key handling, rotating a key, and what never to send