---
title: "Errors"
description: "Ordering API responses normally use an envelope with an error flag and a result value."
canonical: https://docs.ordering.co/api-reference/guides/errors/
---

# Errors

Ordering API responses normally use an envelope with an `error` flag and a `result` value. A successful JSON response generally looks like this:

```json
{
  "error": false,
  "result": {}
}
```

An error response sets `error` to `true`. `result` usually contains one or more messages, and validation errors can also include machine-readable `error_codes`.

```json
{
  "error": true,
  "result": [
    "You do not have permission."
  ]
}
```

The message can vary with the selected API language. Do not use its English text as a stable programmatic identifier.

## HTTP status codes

The status codes supported by the current contract include:

- `200` — the operation completed and returned a normal response envelope.
- `302` — the documented operation redirects the client.
- `400` — invalid input or an operation-specific business rule failed.
- `401` — authentication is missing or invalid, the caller lacks the required access level, or project access failed.
- `403` — the operation explicitly refused an authenticated request.
- `404` — the requested API version is not supported; a small number of operations also document an explicit operation-specific `404`.
- `409` — the request conflicts with current resource state.
- `500` — an unexpected server or project-initialization failure occurred.
- `503` — the API or project is temporarily unavailable or in maintenance.

Not every operation returns every code in this list. Treat the response table for the specific operation in API Reference as authoritative.

## Handle errors safely

Check the HTTP status and the envelope's `error` flag. Display `result` messages when useful, but branch on documented status codes or `error_codes` rather than matching translated human-readable text.