All API error responses follow the RFC 7807 Problem Details standard. Each problem type has a stable URI that serves as the type field in error responses, plus a directory page documenting its description, example response, and any type-specific fields.

Response shape

Every error response uses the application/problem+json content type and includes a stable type URI you can branch on programmatically:

{
  "type": "https://docs.avvail.com/v2/problems/not-found",
  "title": "Not Found",
  "detail": "The requested resource could not be found",
  "instance": "/v2/reservations/abc-123"
}

The type URI is the integration contract — it does not change across releases for the same problem type, even if the human-readable title or detail is updated.

Problem types

The full directory of every error type the API can return. Click a type for an example response and its full type URI.

Handling errors

Validation errors

Validation errors (HTTP 422) include an errors array with field-level details:

{
  "type": "https://docs.avvail.com/v2/problems/validation-error",
  "title": "Validation Error",
  "detail": "Validation failed for one or more fields",
  "instance": "/v2/reservations",
  "errors": [
    {
      "message": "must be in the format 'HH:MM'",
      "pointer": "/time",
      "code": "invalid"
    }
  ]
}

Each entry in the errors array includes:

Retry strategy

• 429 (Rate Limit): Respect the Retry-After header before retrying. See Advanced Usage for rate limit details.
• 500 (Server Error): Use exponential backoff with jitter (e.g., 1s, 2s, 4s).
• 4xx errors: Do not retry — fix the request based on the error details.