Reintentos

Cuando OrderFast envía un evento a tu URL, espera una respuesta 2xx en menos de 30 segundos. Si tu ERP 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

Desactivar un endpoint

Si desactivás un webhook endpoint vía PATCH /v2/webhook-endpoints/:id con status: inactive, OrderFast deja de enviar eventos a esa URL sin marcarlos como fallidos.

Qué debe hacer tu ERP

Responder rápido

La conciliación con tu ERP puede ser lenta, pero tu endpoint HTTP debe responder de inmediato:

1. Validá la firma.
2. Respondé 200.
3. Encolá el procesamiento (cola de mensajes, worker, etc.).

Esto es especialmente importante para eventos de alto volumen como order.created o sync.completed.

Ser idempotente

El mismo evento puede llegar más de una vez. Usá X-OrderFast-Event-Id 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).

Esto es crítico para eventos como settlement.created o sync.completed, donde reprocesar podría generar duplicados contables.

No depender del orden

Los eventos pueden llegar fuera de orden. Por ejemplo:

• sync.completed puede llegar antes que el último stock.updated del batch.
• payment.completed puede llegar antes que order.status_changed.

Diseñá tu lógica para consultar el estado actual del recurso vía API cuando necesites el dato definitivo.

Diagnosticar fallos

Consultá el historial de entregas:

GET /v2/webhook-endpoints/: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 /v2/webhook-endpoints/:id/test

Relacionado

• Overview — registrar y gestionar webhook endpoints
• Firma HMAC — validar eventos entrantes
• Eventos — estructura de payloads