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

# Errors

> Conventional HTTP status codes, with a consistent JSON error body.

DMLY uses conventional HTTP status codes. Anything in the `2xx` range succeeded; `4xx`
means the request was wrong; `5xx` means something broke on our side.

Every error returns the same envelope:

```json theme={"dark"}
{ "message": "No query results for model [Contact]." }
```

Validation errors add a per-field breakdown:

```json theme={"dark"}
{
  "message": "The name field is required.",
  "errors": {
    "name":  ["The name field is required."],
    "email": ["The email must be a valid email address."]
  }
}
```

## Status codes

| Code  | Meaning                                                             | What to do                                                    |
| ----- | ------------------------------------------------------------------- | ------------------------------------------------------------- |
| `401` | Missing, invalid, or revoked API key — or its workspace was deleted | Check the key. Do not retry as-is                             |
| `403` | API access is disabled for this installation                        | Contact your administrator                                    |
| `404` | No such resource **in this workspace**                              | Check the id, and that the key belongs to the right workspace |
| `422` | Validation failed                                                   | Read `errors` and fix the request                             |
| `429` | [Rate limit](/api-reference/rate-limits) exceeded                   | Back off, honour `Retry-After`                                |
| `5xx` | Something broke on our side                                         | Retry with backoff; if it persists, get in touch              |

## A note on 404

The API is workspace-scoped by the key. A resource that exists but belongs to a *different*
workspace returns `404`, not `403` — from your key's point of view it genuinely does not
exist. If you are certain an id is valid and still get `404`, you are almost always using a
key from the wrong workspace.

## Retrying safely

`GET` and `DELETE` are idempotent — retry freely.

`POST` is **not**. A create that times out may still have succeeded, so a blind retry can
produce a duplicate. When retrying a `POST`, search for the record first, or key off
something unique (a contact's phone number) to check before recreating.

<Tip>
  Retry `429` and `5xx` with exponential backoff. Never retry `401`, `403`, or `422` — the
  same request will fail identically every time.
</Tip>