> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chift.eu/llms.txt
> Use this file to discover all available pages before exploring further.

# Idempotency

To prevent duplicate resource creation, you can include a unique value in the `X-Chift-Client-RequestId` header of your POST request (such as one that creates an invoice).

This ensures that Chift processes each POST request exactly once. Uniquely identifying POST requests that create new resources is particularly crucial when the response outcome is uncertain. This can happen during temporary service disruptions, such as server timeouts or network failures.

In such cases, your application can safely retry the request without the risk of duplicate operations. API endpoints that process a request only once, no matter how many times you retry it with the same unique identifier, are called idempotent.

## How to use it?

Include the following header in your request to Chift:

`x-chift-client-requestid: 123456`

The value (`123456` in this example) is a unique identifier that you generate and manage on your side:

1. **Format and storage:** It must be a **varchar(255)**, meaning it can contain up to 255 characters. You are responsible for generating it in a way that guarantees uniqueness for each request.
2. **Scope and usage:** The header is not tied to a specific endpoint and can be included in any request. Each value must be unique per request, regardless of the endpoint, to ensure duplicates are correctly detected.
3. **Uniqueness per connection:** The request id must be unique **per connection**. The same value can safely be reused across different connections without conflict, but reusing it within the same connection is detected as a duplicate.
4. **Time to live:** Chift keeps logs of these identifiers for **6 months**.
5. **Failed requests:** Only successful requests consume the identifier. If a request fails (network error, validation error, etc.), the same identifier can be reused safely.
6. **No reset mechanism:** Once an identifier is consumed by a successful request, it cannot be deleted or reset. Use a new unique value for each new request.

## What can you expect?

Chift returns a 409 error code if your request was already processed (`REQUEST_ALREADY_PROCESSED`) or is currently being processed (`REQUEST_IN_PROCESS`).

For example:

```text theme={null}
{
    "status": "error",
    "message": "Request already processed: 200",
    "detail": "Request with same client request id {client_request_id} was already successfully processed",
    "error_code": "REQUEST_ALREADY_PROCESSED"
}
```

```text theme={null}
{
    "status": "error",
    "message": "Request is in processing",
    "detail": "Request with same client request id {client_request_id} is currently processed",
    "error_code": "REQUEST_IN_PROCESS"
}
```

## Monitoring

The transaction endpoint ([API Reference ↗️](/api-reference/endpoints/connections/get-transaction-information)) allows you to retrieve detailed information about any API transaction using the `x-chift-client-requestid`. This is particularly useful for auditing, troubleshooting, or tracking the status of a request.

For **POST endpoints**, the response also returns the `created_entity_id`, giving you the identifier of the newly created entity directly in the monitoring response.

**Key points:**

* This endpoint is ideal for monitoring asynchronous or long-running operations, providing a single source of truth for the status and result of any request.
* You may decide to implement a **timeout** on your requests, for example terminating the connection after 30 seconds or 1 minute. In that case, Transaction Monitoring allows you to track the outcome of requests that continue executing on Chift even after your timeout has cut the connection.
* The monitoring endpoint works across all connectors.
* Chift deletes transactions after 6 months, so idempotency is only valid during that period.