> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wavebybemobi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Errors

> How the Wave API reports errors, following the RFC 9457 problem details standard

When a request fails, the Wave API responds with a non-`2xx` HTTP status code and a JSON body that describes what went wrong. Error bodies follow [RFC 9457 — Problem Details for HTTP APIs](https://www.rfc-editor.org/rfc/rfc9457.html) and are served with the `application/problem+json` content type.

```json Example error response theme={null}
{
  "type": "https://wave.com/errors/unauthorized",
  "title": "Unauthorized",
  "status": 401,
  "detail": "Invalid or missing authentication credentials",
  "instance": "/lines"
}
```

## Fields

| Field      | Type    | Description                                                                                                    |
| ---------- | ------- | -------------------------------------------------------------------------------------------------------------- |
| `type`     | string  | URI that identifies the problem type. This is the stable identifier for the error — branch on it in your code. |
| `title`    | string  | Short, human-readable summary of the problem type.                                                             |
| `status`   | integer | HTTP status code, repeated in the body for convenience. Always matches the response status.                    |
| `detail`   | string  | Human-readable explanation specific to this occurrence of the problem.                                         |
| `instance` | string  | URI reference of the request that produced the error.                                                          |

A problem details object may also carry extension members — additional fields specific to a problem type, as allowed by [Section 3.2 of the RFC](https://www.rfc-editor.org/rfc/rfc9457.html#section-3.2). Ignore any field you do not recognize instead of failing to parse the response.

## Handling errors

* **Branch on `status` and `type`.** The HTTP status code tells you the class of failure (a `4xx` means the request needs to change, a `5xx` means the request can be retried); `type` tells you exactly which problem occurred.
* **Do not parse `detail` or `title`.** Both are meant for humans — the wording can change at any time without being a breaking change. Show them in logs and error messages, but never key application logic off them.
* **Accept `application/problem+json`.** Some HTTP clients only deserialize `application/json` by default and will hand you an unparsed string otherwise.
* **Log `instance` and the request path.** Include them when you contact support so we can trace the exact call.

<Note>
  Requests to a path that does not exist are rejected before reaching the API's error handling and return a plain `application/json` body instead of problem details:

  ```json theme={null}
  {
    "message": "Route DELETE:/management/health not found",
    "error": "Not Found",
    "statusCode": 404
  }
  ```

  If you see this shape, check the method and path against the endpoint reference.
</Note>

<Note>
  Getting an error you cannot explain? Contact us at [support-wave@bemobi.com](mailto:support-wave@bemobi.com).
</Note>