Skip to main content
Todas las escrituras exigen la cabecera Idempotency-Key con un identificador único que genera tu sistema:

Por qué es obligatoria

Porque el caso malo es silencioso. Envías un lote de 300 entradas, se agota el tiempo de espera y no sabes si llegó. Si reintentas sin clave de idempotencia y sí había llegado, acabas con 600 entradas y nadie se entera hasta que el aforo no cuadra el día del evento. Con la cabecera, el reintento devuelve la respuesta original y no ejecuta nada.

Comportamiento

Misma clave, mismo cuerpo

Devuelve la respuesta guardada, sin volver a ejecutar. La respuesta lleva la cabecera Idempotent-Replayed: true.

Misma clave, cuerpo distinto

422 idempotency_key_reused. Es una red de seguridad: significa que has reutilizado una clave por error.

Clave en vuelo

409 idempotency_in_flight si la operación se está procesando en ese instante. Espera un segundo y reintenta.

Claves distintas

Dos operaciones independientes. Enviar el mismo lote con dos claves distintas crea todo dos veces.

Cómo generar la clave

Un UUID v4 vale. Lo importante es que sea estable entre reintentos de la misma operación lógica y distinta entre operaciones distintas.
Si tus operaciones tienen ya un identificador propio —el número de pedido, por ejemplo— úsalo. Es más robusto que un UUID en memoria, porque sobrevive a que se caiga tu propio proceso:

Alcance

La clave es tuya: dos integradores distintos pueden usar el mismo valor sin pisarse, y la misma clave en dos endpoints distintos son dos operaciones distintas. Las operaciones completadas se recuerdan 7 días. Pasado ese plazo, la misma clave se trata como una operación nueva.

El caso de la acreditación

POST /tickets/{code}/check-in usa la Idempotency-Key como identificador del escaneo. Eso lo hace especialmente seguro de reintentar: si la red se cortó justo después de canjear la entrada, el reintento devuelve la misma pulsera en lugar de emitir una segunda. Genera una clave por escaneo físico y consérvala mientras dure el reintento: