Skip to content

Loading…

Errors

Standard problem responses, request IDs and safe retry rules.

On this page

Errors use HTTP status codes and application/problem+json (RFC 9457):

JSON
{
  "type": "about:blank",
  "title": "Forbidden",
  "status": 403,
  "detail": "Insufficient scope",
  "instance": "/v1/properties",
  "request_id": "0123456789abcdef0123456789abcdef"
}

The same correlation ID appears in X-Request-Id. Keep it when contacting support. Errors never echo API keys, request bodies, SQL text or storage credentials. Branch on HTTP status rather than matching the message.

Status codes

StatusMeaningAction
400An upload or existing form request cannot be processed.Correct the request.
401Missing, malformed, unknown, expired or revoked key.Correct or rotate the key.
403Valid key without the required scope.Create a key with the needed permission.
404Resource does not exist in the workspace, or listing is not public.Do not infer whether another workspace owns it.
409Duplicate contact or an idempotency/session key used with a different request.Reconcile the existing resource or use a new key for a new request.
422Invalid fields, incompatible pricing or incomplete publication data.Correct all reported fields.
500Unexpected server error.Retry safely with backoff; keep the request ID.

Validation errors

A 422 can include errors, each containing type, loc and msg. For example, loc: ["body", "pricing", "sale"] identifies the invalid field. Input values are deliberately omitted.

Retry rules

GET requests are safe to retry. Property and contact creation support idempotency keys: reuse the same key and body after a lost response. Without a key, check whether creation succeeded before retrying. Repeating the same publication request is safe. Do not poll failed jobs indefinitely; correct the cause first.

Existing rental ingestion ignores known phone numbers; inquiry creation can return a conflict when a previous attempt was stored. Server-side outreach errors do not expose internals.