Reintentos

Cuando OrderFast envía un evento a tu URL, espera una respuesta 2xx en menos de 30 segundos. Si tu servidor no responde a tiempo, devuelve un error, o responde con un código distinto de 2xx, el evento se considera fallido y OrderFast lo reintenta automáticamente.

Política de reintentos

Intento	Cuándo
1	Inmediato
2	+1 minuto
3	+5 minutos
4	+15 minutos
5	+1 hora

Después del quinto intento fallido, el evento se marca como dead y no se vuelve a enviar.

Qué cuenta como fallo

Situación	Resultado
Tu servidor responde `2xx`	Entrega exitosa
Timeout (> 30 s)	Fallo → reintento
Respuesta `4xx` o `5xx`	Fallo → reintento
Error de conexión (DNS, TLS, red)	Fallo → reintento

Qué debe hacer tu servidor

Responder rápido

Procesá el evento de forma asíncrona si tu lógica es pesada:

Validá la firma.
Respondé 200 de inmediato.
Encolá el procesamiento en background (cola, worker, etc.).

No hagas operaciones lentas (llamadas a ERP, emails, etc.) antes de responder.

Ser idempotente

El mismo evento puede llegar más de una vez. Usá X-OrderFast-Event-Id (o el campo id del body) para detectar duplicados:

Si ya procesaste ese id, respondé 200 sin repetir la acción.
Guardá los IDs procesados con un TTL razonable (al menos 24 horas).

No depender del orden

Los eventos pueden llegar fuera de orden. Por ejemplo, payment.completed podría llegar antes que order.updated. Diseñá tu lógica para manejar esto consultando el estado actual del recurso si es necesario.

Diagnosticar fallos

Consultá el historial de entregas para ver qué pasó:

GET /v1/webhooks/:id/deliveries

Cada entrada incluye el tipo de evento, número de intento, estado (delivered, failed, dead) y el código HTTP que devolvió tu servidor.

También podés enviar un evento de prueba:

POST /v1/webhooks/:id/test

Relacionado

Overview — registrar y gestionar webhooks
Firma HMAC — validar eventos entrantes
Eventos — estructura de payloads