Errors - Reconify Developer Docs

The API returns errors as JSON. Most application errors use an RFC 7807-compatible application/problem+json envelope:

{
  "title": "Not Found",
  "status": 404,
  "detail": "request body is invalid",
  "errors": [{ "location": "$code", "message": "invalid_event" }]
}

Use the HTTP status as the first decision point. Use detail for a human-readable explanation and the machine-readable error code when present. Do not branch on prose that may change.

Common statuses

Status	Action
`400`	The request body or event fields are invalid. Fix the request; do not retry unchanged.
`401`	The key is missing, malformed, expired, revoked, or invalid. Replace the credential.
`403`	The key is valid but lacks write scope or feature access. Check authorization.
`404`	The route does not exist. Check the URL and API version.
`409`	The submission conflicts with existing event identity or state. Resolve the conflict.
`422`	Event validation failed. Correct the fields identified in the result.
`429`	A request or organization capacity limit was reached. Back off and retry safely.
`503`	Durable ingestion or a required dependency is unavailable. Retry with backoff and jitter.

500 indicates an unexpected server failure. Preserve the request ID and contact support if retries continue to fail.

Retry safety

Do not retry unchanged 400, 401, 403, 404, or 422 requests.
Retry 429 and 503 with exponential backoff and jitter.
Reuse a stable event id when retrying the same event.
Inspect the index-aligned response before retrying a partial batch.
Preserve the response request ID when reporting a failure.

Never log bearer tokens, full event bodies, or customer financial data. If an issue persists, send the request ID and a redacted error response to support@reconifyhq.com.

⌘I