Error model

Each per-endpoint Errors section lists the status codes and causes for that endpoint. This page covers the response shape — what the response body looks like across the API.

Status codes

Status	Meaning
400 Bad Request	The request failed schema validation, or the handler rejected it (validation rule failure, malformed input, missing user_key).
401 Unauthorized	The bearer token is missing or invalid.
403 Forbidden	The caller is authenticated but not authorized — the bearer token is missing the required scope, or user_key does not match a known agency, or the agency is not authorized for the requested market or currency combination.
404 Not Found	The resource — typically a booking session — does not exist or has expired.
409 Conflict	The session state does not permit the call (e.g. operating on a session of the wrong type, removing an addon flagged as mandatory).
500 Internal Server Error	Something went wrong on the server. Retry the call; if the error persists, report the correlationId from the response body.

Response body shape

Every error response with a body uses application/problem+json with the same envelope:

{
  "status": 400,
  "title": "Validation failed.",
  "detail": "One or more fields failed validation.",
  "correlationId": "8c2f3b2d-1d6f-4f3a-9c5d-3a7b1e6f4b2d",
  "errors": {
    "Cabins": [
      "Cabins must not be empty.",
      "Total number of guests must not exceed 9."
    ],
    "Date": [
      "'Date' must not be empty."
    ]
  }
}

Top-level envelope keys are camelCase. The errors dictionary keys are PascalCase — they mirror the request-body field names.

The same envelope is returned for 400, 403, 404, 409, and 500.

Field	Always present	Meaning
status	yes	The HTTP status code, repeated in the body for convenience.
title	yes	A short, fixed summary of the error class (e.g. "Validation failed.", "Conflict.", "An unexpected error occurred.").
detail	yes	A human-readable explanation of the specific cause. Short, fixed strings — partners should branch on the per-endpoint Cause column rather than parsing this text.
correlationId	yes	Server-generated identifier tying the request to its server-side log entry. Include this when contacting support.
errors	only on validator 400s	Object keyed by request property; each value is an array of error messages for that property. Property keys are PascalCase and match the request-body field names. Field-specific causes are listed under each endpoint's Validation rules.

correlationId is server-generated; client-supplied X-Correlation-ID request headers are not echoed back to the response and should not be relied on. Include the correlationId in any support report for an error with a body.

Bodyless responses

Two cases return only a status code and no body:

• 401 Unauthorized — returned with a WWW-Authenticate: Bearer response header when the bearer token is missing or invalid. Debug by inspecting the WWW-Authenticate header and confirming a valid token was sent.
• 403 Forbidden, missing-scope variant — returned when the bearer token authenticates successfully but lacks the scope required by the V2 API. Debug by inspecting the token's scope claim.

Other 403s (unknown user_key, market/currency mismatch) return the standard envelope. There is no correlationId for the bodyless cases — both are pre-authorization-check rejections and partners should debug via the token rather than via a server-side log entry.