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

# idempotency_key_reuse

> Resolve HTTP 409 conflicts: distinguish a request still running from an Idempotency-Key reused with different input.

| | |
| - | - |
| **Code** | `idempotency_key_reuse` |
| **HTTP status** | `409 Conflict` |
| **Retryable** | Read `retryable` in the response |

## Choose the right recovery

The same error code describes two different situations. Check `retryable` before
acting; HTTP status alone does not tell you whether to retry.

| Response | Meaning | Next step |
| - | - | - |
| `retryable: false` | The key already identifies a request with different input. | Compare the body with the original request. Use a new key only for an intentionally different operation. |
| `retryable: true` | Another request using the key is still processing. | Keep the same key and request. Wait at least `Retry-After` seconds, then retry within a bounded time budget. |

### Different input

```json theme={null}
{
  "type": "https://docs.livingsecurity.com/developers/v1/errors/idempotency_key_reuse",
  "title": "Conflict",
  "status": 409,
  "detail": "Idempotency-Key was already used with a different request.",
  "code": "idempotency_key_reuse",
  "request_id": "req_0199a1e0-7c00-7000-8000-000000000001",
  "doc_url": "https://docs.livingsecurity.com/developers/v1/errors/idempotency_key_reuse",
  "retryable": false,
  "param": "Idempotency-Key"
}
```

### Request still processing

This example also has the HTTP response header `Retry-After: 1`.

```json theme={null}
{
  "type": "https://docs.livingsecurity.com/developers/v1/errors/idempotency_key_reuse",
  "title": "Conflict",
  "status": 409,
  "detail": "A concurrent request is still processing this Idempotency-Key. Retry shortly.",
  "code": "idempotency_key_reuse",
  "request_id": "req_0199a1e0-7c00-7000-8000-000000000001",
  "doc_url": "https://docs.livingsecurity.com/developers/v1/errors/idempotency_key_reuse",
  "retryable": true,
  "param": "Idempotency-Key"
}
```

## Keep the retry identity stable

For operations that document idempotency, the key is scoped to the organization,
service account, HTTP method, resource path and resolved API version. Changing
any of those creates a different retry identity; it does not recover the original
operation. Rotating a credential under the same service account does not change
that identity, although the replacement credential must still have permission.

Keep the original key, body, path and version when recovering from a timeout.
Do not generate a fresh key merely to get past a conflict: the original write
may already have succeeded. Retrieve the resource when its ID is known and use
the operation's documented recovery procedure. A completed replay carries
`Idempotent-Replayed: true` where the operation documents response replay.

Sending an `Idempotency-Key` does not make an operation idempotent unless its
reference explicitly supports that header. Retry protection is bounded by the
operation's retention policy; it is not a permanent guarantee against duplicates.

If processing remains unresolved, contact [Living Security Support](mailto:support@livingsecurity.com)
with the `request_id`, UTC timestamp, method, path and API version. Never include
an API key, client secret or access token.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.