> 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/v2/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 (for example: `401 Unauthorized – No valid credentials given`).

## HTTP Status Codes <a href="#id-401-unauthorized" id="id-401-unauthorized"></a>

A 2xx response has the meaning defined by the endpoint. In particular, `202 Accepted` from the order and tracking ingestion endpoints means that the request was accepted for asynchronous processing. It does not confirm that every record has been stored or that carrier data is already available. See [Successful ingestion responses](/docs/developers/v2/orders/trackings-orders.md#successful-ingestion-responses).

API v4 also performs validation before it accepts an order request and returns per-mutation results. For example, it can reject a tracking number and carrier pair already assigned to another order with `400 Bad Request`. For `200 OK` or `201 Created`, inspect each mutation's `success`, `message`, `errors`, and `warnings`. See [v4 ingestion results and validation](https://github.com/parcelLab/gitbook-documentation/tree/main/developers-v4/orders/create-orders-trackings.md#ingestion-results-and-validation).

For data-ingestion issues reported during processing, open the [parcelLab App](https://app.parcellab.com/) and select your profile icon > **Notifications**. **Track creation failed** notifications show when received data could not be stored as a tracking, for example *Duplicate Tracking Not Stored*, with a timestamp, occurrence count, and expandable details and metadata. See [Notifications](https://docs.parcellab.com/guides/admin-and-settings/notifications) for notification types and troubleshooting controls. Check these notifications alongside the API response and later status lookups.

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 <a href="#id-401-unauthorized" id="id-401-unauthorized"></a>

Some example error codes are described in the following table.

<table><thead><tr><th width="132.21875">Status Code</th><th width="197.0859375">Error</th><th>Description</th></tr></thead><tbody><tr><td>400</td><td>Bad Request</td><td>This is returned when there is an issue with the information provided in the request, often due to incorrect format or missing required parameters/fields.</td></tr><tr><td>401</td><td>Unauthorized</td><td>This is returned when the authentication fails or the authentication information is not provided as part of the request.</td></tr><tr><td>403</td><td>Forbidden</td><td>This is returned when the client does not have the rights to perform the request.</td></tr><tr><td>404</td><td>Not Found</td><td>This is returned when the requested resource cannot be found.</td></tr><tr><td>405</td><td>Method Not Allowed</td><td>This is returned when an endpoint is called with an unexpected HTTP method.</td></tr><tr><td>500</td><td>Internal Server Error</td><td>This is returned when the API server encounters an unexpected error.</td></tr></tbody></table>


---

# 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/v2/getting-started/error-codes.md?ask=<question>&goal=<user_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.