# Errors


Endpoints and request limiters answer every error with the same JSON body: a `status` field that is always `error` and a short `error` message.

```json
{"status": "error", "error": "Invalid ticker"}
```

> [!NOTE]
> `status` is always `error` and `error` is a short message you can show or log. Do not parse the message to make decisions; use the HTTP status.

| HTTP | Examples | What to do |
| --- | --- | --- |
| `400` | `Invalid ticker`, `Address is invalid`, `Callback URL is not a valid URL`, unsupported or duplicate parameters, a payout address that differs from the one already bound to the pair | Fix the request. Retrying unchanged will fail again. |
| `404` | `Callback not found` from logs for an unknown pair, `Address not found` from qrcode | Check the ticker and callback or address. Create the order first. |
| `429` | `Rate limit exceeded`, `New order creation limit exceeded` | Back off and retry later. Reusing an existing pair avoids the new-order limit but still counts toward the request limit. |
| `503` | A paused network, a low pool of free addresses, `Ticker is temporarily unavailable`, `Network fee estimate unavailable`, `Price data is temporarily unavailable`, or a transient processing failure | Retry later with exponential backoff. |

> [!NOTE]
> Failures raised before a request reaches an endpoint, such as an unknown route, a method other than `GET`, an oversized request or a timeout, are answered by the gateway's middleware and may use a different body.

## Common causes

- `Invalid ticker`: the ticker is not lowercase, is missing the token part, or is not in [Tickers and networks](tickers.md).
- `Address is invalid`: the payout address does not belong to the ticker's network, or is controlled by the gateway.
- Immutable payout: the pair already exists with another payout address. Use a new callback URL for a new payout address.
- `Callback URL is not a valid URL`: the callback must be a public HTTPS URL, and private or loopback destinations are refused.

## Callback failures

A callback that your server answers with anything other than `200` and `*ok*` is retried on the schedule in [Callbacks](callbacks.md). Failed deliveries are visible in the `logs` of the order.
