Saltar al contenido principal

Idempotencia

Un fallo de red puede dejarle sin saber si una solicitud llegó. Sin protección, el reintento aparentemente seguro podría verificar dos veces la misma dirección. Una clave de idempotencia hace inofensivo el reintento: la API la reconoce y responde con el resultado que ya registró.

Envíe Idempotency-Key: <valor> en cualquier solicitud que cree algo:

  • POST /v1/checks y POST /v1/checks/batch
  • POST /v1/webhooks, POST /v1/webhooks/{webhook_id}/rotate y DELETE /v1/webhooks/{webhook_id}
  • POST /v1/telegram/link-codes y DELETE /v1/telegram/links/{link_id}

El encabezado es opcional. El valor tiene de 1 a 255 caracteres ASCII imprimibles sin espacios; cualquier otro se rechaza con 400 VALIDATION_ERROR y parameter: "idempotency-key". Use su propio identificador de operación (un número de pedido, un identificador de pago), no un valor aleatorio por intento: lo esencial es que todos los intentos de una misma operación envíen la misma clave.

Una clave se limita a su cuenta, al entorno de la clave (live o sandbox) y al endpoint, de modo que el mismo valor en dos endpoints, o con una clave sandbox y una live, no colisiona. Las claves se recuerdan durante 24 horas; después el valor puede reutilizarse.

Qué ocurre cuando se reutiliza una clave​

Usted envíaLa API responde
La clave por primera vezEjecuta la solicitud y registra su resultado bajo la clave.
La misma clave y el mismo cuerpo, una vez terminada la primera solicitudReproduce el resultado registrado: el mismo código de estado y el mismo recurso (en una verificación, el mismo check_id). No se verifica ni se cobra nada otra vez.
La misma clave y un cuerpo distinto422 IDEMPOTENCY_KEY_CONFLICT. No se ejecuta nada.
La misma clave mientras la primera solicitud sigue en curso409 IDEMPOTENCY_REQUEST_IN_FLIGHT. Espere un momento y envíela de nuevo.
La misma clave después de que un reintento simultáneo tomara el arrendamiento de la primera solicitud409 IDEMPOTENCY_LEASE_LOST para la solicitud que lo perdió. Envíe de nuevo la misma solicitud para leer el resultado registrado.

Detalles que importan en la práctica:

  • «El mismo cuerpo» significa los mismos bytes. El cuerpo se compara tal como se envía, no tras analizarlo, así que un reintento que reserialice el JSON con otro orden de claves o espaciado cuenta como un cuerpo distinto. Guarde la solicitud serializada y reenvíela sin cambios.
  • Solo se registran los resultados correctos. Una solicitud que termina en 4xx o 5xx no queda asociada a su clave, así que un reintento se ejecuta de nuevo, que es lo que se quiere tras un fallo transitorio. Si el error fue un 4xx, corrija antes la solicitud.
  • Una solicitud caída no bloquea la clave. Si el primer intento muere sin responder, un reintento toma la clave tras 30 segundos.
  • El secreto de un webhook se muestra una sola vez. Reproducir POST /v1/webhooks o una rotación devuelve el webhook sin su secret, porque el secreto nunca se guarda en forma legible. Si perdió la respuesta, rote con una clave nueva.
  • Los elementos de un lote reciben claves derivadas. La clave de cada elemento de un lote se forma con la clave del lote y su posición, de modo que reproducir un lote no puede verificar un elemento dos veces.

Ejemplo​

Envíe la misma solicitud, con la misma clave y el mismo cuerpo, hasta obtener una respuesta. El cuerpo es la dirección de prueba de sandbox, que siempre responde pending, así que ejecútelo con una clave sandbox.

curl -s -X POST https://api.leeri.ai/v1/checks \
-H "Authorization: Bearer $LEERI_API_KEY" \
-H "Idempotency-Key: deposit-2291-attempt-group" \
-H "Content-Type: application/json" \
-d '{"subject":"address","asset":"BTC","address":"1PENDNGCHECKADDRESSFRSANDBXTEST99"}'

Ejecútelo dos veces: la segunda respuesta lleva el mismo check_id que la primera.

Para reaccionar ante otros fallos, vea Errores.