Idempotencia

Las redes fallan. Si un POST supera el tiempo de espera, no sabes si se aplicó, y reintentar a ciegas podría crear un producto duplicado. El header Idempotency-Key lo resuelve:

curl -X POST https://api.nembol.com/rest/v1/products \
  -H "Authorization: Bearer $NEMBOL_API_KEY" \
  -H "Idempotency-Key: 7d5c1f6e-2f5b-4a1e-9c3d-0a8b7c6d5e4f" \
  -d '{ "title": "…" }'

• Genera una clave única por operación lógica (un UUID es perfecto), y reutiliza la misma clave al reintentar esa operación.
• Repetir la misma clave con el mismo payload devuelve la respuesta original guardada (mismo código de estado y cuerpo, más el header Idempotent-Replayed: true). No se vuelve a ejecutar nada. Los errores también se guardan: un 4xx (p. ej. un 422) se repite tal cual, aunque la causa se haya corregido después por tu parte o por la nuestra, así que envía una clave nueva después de cambiar la petición o tras una corrección. Un 5xx nunca se guarda: reintentar con la misma clave vuelve a ejecutar la petición.
• Repetir la misma clave con un payload distinto falla con 409 (idempotency_key_reused). Las claves nunca se reutilizan en silencio.
• Las claves se recuerdan durante 24 horas; longitud máxima de 255 caracteres.

Compatible (y recomendado) en todos los endpoints POST, PATCH y DELETE.

Receta de reintento: ante un timeout o un 5xx, reintenta con la misma clave y backoff exponencial (p. ej. 1 s, 2 s, 4 s, …); ante un 429, espera Retry-After y reintenta con la misma clave.

Última actualización el 20 de octubre de 2026