Skip to main content
Use the HTTP status and the string code field to handle Main API errors. The documented error shape follows RFC 7807 Problem Details with Spotzee-specific fields. Clients must also handle responses that omit optional fields or use application/json during the conventions rollout.
Use the HTTP status as a fallback when a response has no recognised string code. Include X-Request-Id when reporting a failed request.
Numeric code values are deprecated. Earlier releases occasionally returned numeric values like 1007, 6000, or 9000 in the code field. Those came from legacy internal catalogues and were never part of the public contract. Never switch on them. The current API returns only the string codes from the catalogue below; if you ever see a numeric code, treat it as an unrecognised error and key off the HTTP status instead.

Error body shape

Once the rollout completes, error responses set Content-Type: application/problem+json.

Per-field errors

When code is validation_failed, the errors array lists every offending field:

Status codes

Code catalogue

The code field is stable and documented. Add new codes to your switch statement only when you need to handle them differently. The catalogue is additive.

Retry guidance

  • Reads (GET): use bounded retries with backoff on 5xx and 429. Honour Retry-After when present.
  • Mutations (POST / PATCH): check idempotency availability and limits before retrying. A timed-out request may have taken effect. Resolve validation or permission errors before retrying; idempotency_in_progress explicitly permits a delayed retry.

Reporting bugs

Always include the request_id (in the response body or the X-Request-Id header) when reporting an error. It lets us trace your specific request end-to-end.

Next steps

Idempotency

Make retries safe.

Rate limits

Avoid 429 with self-throttling.