> For the complete documentation index, see [llms.txt](https://docs.parcellab.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.parcellab.com/docs/developers/getting-started/error-codes.md).
# Error Codes
Quickly identify and resolve API request failures.
## Overview
The parcelLab API uses standard HTTP status codes to indicate whether a request was successful or not. In case of an error, the response body will contain details of the error in a JSON object with the following structure.
```json
{
"type": "client_error",
"errors": [
{
"code": "error_code",
"detail": "Error message.",
"attr": "Optional additional information."
}
]
}
```
## HTTP Status Codes
When you make an API call, receiving a 2xx response (for example: 200 OK) would indicate that the client’s request was successfully received, understood, and processed by the server.
For a failed API request, error codes are categorized into different groups to indicate specific issues encountered during the request process:
* 4xx client errors - these codes indicate issues with the client's request (for example: incorrect parameters or unauthorized access)
* 5xx server errors - these codes indicate that the server failed to process the request
## Error Code Examples
Some example error codes are described in the following sections.
### 400 Bad Request: Invalid PK
For `PUT /v4/track/orders/`, the API can return this account-access error:
```json
{"detail": "Invalid PK"}
```
`PK` means primary key. For this endpoint, check the parcelLab account associated with the request and order:
1. Set `account` to the numeric parcelLab account ID, not a shop name or order number.
2. Use an API token issued for that account or one of its parent accounts, with the `write` scope. A token with `track:write` is also accepted.
3. If you update an existing order by `external_id`, check that the token can access the account that owns the order.
Correct the account or token before you retry. This response uses a direct `detail` field instead of the `errors` list shown above. If the error occurs at another endpoint, send parcelLab support the endpoint, HTTP status, and response body, without your API token.
See [Create Orders/Trackings](/docs/developers/orders/create-orders-trackings.md) for the request format.
### 401 Unauthorized
These errors are returned with the status code 401 whenever the authentication fails or a request is made to an endpoint without providing the authentication information as part of the request. Here are the two possible errors that can be returned.
```json
{
"type": "client_error",
"errors": [
{
"code": "authentication_failed",
"detail": "Incorrect authentication credentials.",
"attr": null
}
]
}
```
```json
{
"type": "client_error",
"errors": [
{
"code": "not_authenticated",
"detail": "Authentication credentials were not provided.",
"attr": null
}
]
}
```
### 405 Method Not Allowed
This is returned when an endpoint is called with an unexpected http method (for example: if updating a user requires a POST request and a PATCH is issued instead) this error is returned. Here's how the response would look.
```json
{
"type": "client_error",
"errors": [
{
"code": "method_not_allowed",
"detail": "Method “patch” not allowed.",
"attr": null
}
]
}
```
### 406 Not Acceptable
This is returned if the `Accept` header is submitted and contains a value other than `application/json`. Here's how the response would look.
```json
{
"type": "client_error",
"errors": [
{
"code": "not_acceptable",
"detail": "Could not satisfy the request Accept header.",
"attr": null
}
]
}
```
### 415 Unsupported Media Type
This is returned when the request content type is not JSON. Here's how the response would look.
```json
{
"type": "client_error",
"errors": [
{
"code": "not_acceptable",
"detail": "Unsupported media type “application/xml” in request.",
"attr": null
}
]
}
```
### 500 Internal Server Error
This is returned when the API server encounters an unexpected error. Here's how the response would look.
```json
{
"type": "server_error",
"errors": [
{
"code": "error",
"detail": "A server error occurred.",
"attr": null
}
]
}
```
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.parcellab.com/docs/developers/getting-started/error-codes.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.