# IDEMPOTENCY_CONFLICT — duplicate request with conflicting payload

The idempotency key is supplied via the `Idempotency-Key` HTTP header on collection create and update requests. See `crud` for the request shape.

<em>cyoda-go version <a href="https://github.com/Cyoda-platform/cyoda-go/releases/tag/v0.6.2">0.6.2</a></em>

# errors.IDEMPOTENCY_CONFLICT

## STATUS

**Not yet implemented (#91).** The error code is reserved and documented here for the future contract, but no API handler currently reads the `Idempotency-Key` header or raises this error. Duplicate collection requests will currently pass through without detection. Tracked for implementation or removal.

## NAME

IDEMPOTENCY_CONFLICT — a request with the same idempotency key was already received but its payload differs from the original.

## SYNOPSIS

HTTP: `409` `Conflict`. Retryable: `no`.

## DESCRIPTION

The idempotency key is supplied via the `Idempotency-Key` HTTP header on collection create and update requests. See `crud` for the request shape.

The server has already processed (or is currently processing) a request with the same idempotency key, but the new request's body or parameters differ from the first one. Idempotency keys protect against duplicate submissions of identical requests; they do not allow modifying the request after the fact.

Not retryable with the same key and a different payload. A distinct operation requires a distinct idempotency key.

## SEE ALSO

- errors
- errors.CONFLICT
- errors.TX_CONFLICT

## See also

- [`cyoda help errors`](/help/errors/) — Every error response from the Cyoda REST API carries a structured `errorCode` in the `properties` object. Multiple codes may share the same HTTP status. Programmatic handling keys on `errorCode`, not HTTP status.
- [`cyoda help errors CONFLICT`](/help/errors/conflict/) — The server detected that the entity was modified by another writer between the time it was read and the time the current write was committed. Normal outcome under concurrent load.
- [`cyoda help errors TX_CONFLICT`](/help/errors/tx_conflict/) — The underlying storage detected a serialization failure (e.g., PostgreSQL error 40001 or 40P01) and aborted the transaction. Normal occurrence under concurrent write load when using serializable or repeatable-read isolation.

## Raw formats

- [`/help/errors/idempotency_conflict.json`](/help/errors/idempotency_conflict.json) — full descriptor (matches `GET /help/{topic}` envelope)
- [`/help/errors/idempotency_conflict.md`](/help/errors/idempotency_conflict.md) — body only