# Handling errors

Source: https://developers.swell.is/backend-api/errors/handling-errors

Swell API libraries return a [validation error](https://developers.swell.is/backend-api/errors/validation-errors) object in case of an invalid `PUT`, `POST`, or `DELETE` request, and *throw* in any other error case.

### Status codes

Failed requests return a standard HTTP status code along with a message describing what went wrong.

| Status | Meaning |
| --- | --- |
| 400 | The request was malformed, or exceeded a documented limit. |
| 402 | The store's plan or trial has expired and must be renewed to continue using the API. |
| 403 | The credentials used aren't authorized for that resource. |
| 404 | No resource exists at that path. |
| 405 | The endpoint doesn't support that HTTP method. |
| 429 | The request was rate limited. |

A `429` means the request waited too long for capacity rather than that it was rejected outright — see [rate limits](https://developers.swell.is/backend-api/rate-limits) for how requests are weighted and how to back off.

Two endpoints report errors differently from the rest. [Transactions](https://developers.swell.is/backend-api/transactions) return typed error codes such as `transaction_conflict` and `transaction_timeout`, and roll back completely when any operation fails. In a [batch](https://developers.swell.is/backend-api/batch-requests), a failed operation returns an `$error` in its own slot of the response while the other operations still apply, so each entry has to be checked individually.