​
Cuándo una entrega cuenta como fallida

Tu servidor tiene que responder con un código 2xx (por ejemplo 200 o 204) en menos de 8 segundos. Cualquier otra cosa cuenta como falla:
  • Un código 4xx o 5xx. Configura la URL final, sin redirecciones.
  • Tardar más de 8 segundos.
  • Un error de red: la URL no existe, el certificado HTTPS no es válido, el servidor está caído.

​
Cuántas veces reintentamos

Si una entrega falla, la reintentamos con esperas cada vez más largas: Después del séptimo intento, la entrega queda como fallida (Falló en el historial) y no se reintenta más. En total, un aviso se intenta durante algo más de un día.
Los reintentos se revisan una vez por minuto, así que los tiempos pueden correrse unos segundos.

​
Cuándo se desactiva un webhook

Si un webhook falla sin parar durante 3 días (ninguna entrega sale bien en ese tiempo), lo desactivamos para no seguir mandando avisos a una URL que no responde. En Ajustes › API y webhooks lo vas a ver como Desactivado, con el último error. Con que una sola entrega salga bien, el contador vuelve a cero. Para reactivarlo, arregla tu servidor y toca Activar. Las entregas que hayan quedado pendientes se mandan en el siguiente minuto.

​
El estado de un webhook en la app

​
El historial de entregas

Entregas muestra los últimos 50 envíos a cada webhook: el evento, cuánto hace, cuántos intentos, el estado (Entregado, Reintentando o Falló) y el código que respondió tu servidor.
Historial de entregas de un webhook
Guardamos el historial durante 30 días.

​
Pausar un webhook

Pausar deja de mandar avisos sin borrar la configuración ni el secreto. Útil mientras haces un mantenimiento. Los eventos que pasen mientras está en pausa quedan pendientes y se mandan cuando lo vuelves a activar (si no pasaron más de 30 días).

​
Si cambias de plan

Si la cuenta pasa a un plan sin API, dejamos de mandar avisos. Los webhooks quedan guardados y vuelven a funcionar si regresas a Escala o Enterprise.

​
Cómo manejar reintentos en tu servidor

1

Responde rápido

Responde 200 apenas verificas la firma y procesa en segundo plano (una cola, un job, un setImmediate). La mayoría de las fallas son timeouts de servidores que hacen todo antes de responder.
2

Evita duplicados

Un reintento trae el mismo id (y el mismo X-Eltick-Delivery). Guarda los ids que ya procesaste y, si llega uno repetido, responde 200 sin hacer nada.
3

No respondas error por algo que no se va a arreglar

Si el evento no te interesa o tiene datos que no puedes usar, responde 200 igual. Un 4xx solo provoca más reintentos.