The Core API returns errors as JSON with a consistent shape. The `code` field is the HTTP status, repeated in the body for clients that don’t have easy access to the response status code.

## Common error responses [Permalink](/content/api/errors/#common-error-responses/index.html)

```
{ "code": 401, "message": "Unauthorized" }
```

```
{ "code": 404, "message": "Not found" }
```

```
{
  "code": 422,
  "message": "Validation Error",
  "errors": [
    { "field": "start", "location": "body", "messages": ["is required"] }
  ]
}
```

## Validation errors (422) [Permalink](/content/api/errors/#validation-errors-422/index.html)

Validation failures return **422** with an `errors` array. Each entry has:

- `field` — the offending parameter name
- `location` — `body`, `query`, or `params`
- `messages` — array of human-readable validation messages; a single field can fail multiple rules at once

## What about the Metrics API? [Permalink](/content/api/errors/#what-about-the-metrics-api/index.html)

WebSocket errors are returned as JSON within the standard response frame format (see [Metrics API overview](/content/api/metrics/overview/index.html)). The shape mirrors the REST error format above — a `code` and a `message`, optionally an `errors` array for validation failures.