Entrega webhooks sin fallar

Disparar un webhook es una línea de código; que sobreviva a un endpoint inestable, un error 500 o un timeout de cinco segundos es donde los equipos pierden una semana en silencio. Este endpoint toma el payload que le da, lo firma, lo entrega con reintentos y le avisa con claridad si no pudo.

La parte de los webhooks que nadie quiere construir dos veces

Todo producto que se integra con el mundo exterior termina necesitando llamar a la URL de otro y confiar en que la llamada llegue. La versión ingenua — un solo POST HTTP sin reintento — falla en silencio en cuanto el receptor se reinicia o hay una falla de red momentánea. notify.webhook es la capa de entrega que los equipos reinventan una y otra vez: espera exponencial, cabeceras de firma, y un lugar donde caen las llamadas que de verdad no se pudieron entregar.

Qué hace una llamada al endpoint

Si el destino responde con un estado fuera del rango 2xx o se agota el tiempo de espera, la entrega se reintenta según un calendario de espera creciente; si se agotan los intentos, la llamada fallida pasa a una cola de fallos y se le reporta con los detalles de la respuesta en vez de desaparecer. POST /notify/webhook recibe una URL destino, un cuerpo JSON y cabeceras personalizadas opcionales, y luego intenta la entrega con una firma HMAC adjunta para que el receptor pueda verificar que el payload realmente vino de ti y no fue alterado en tránsito.

La firma tiene una historia que vale la pena respetar

Firmar el payload de los webhooks se volvió un estándar de facto porque los primeros sistemas de webhooks no tenían forma de probar que un callback no había sido falsificado por un tercero que adivinó la URL. Generamos una firma por cada entrega usando un secreto que usted controla, siguiendo el mismo patrón de cabecera y hash que la mayoría de los consumidores de webhooks modernos ya saben verificar, así que integrar del lado receptor toma minutos, no una revisión de especificación.

Dónde encaja dentro de un flujo más grande

Encadénelo después de una decisión de enrutamiento de alertas, o úselo como el tramo saliente de una tarea que necesita avisar a un sistema aguas abajo en cuanto el trabajo termina. Como la entrega es asíncrona y se rastrea por task_id, puede disparar un webhook desde dentro de otra automatización — un evento de pago, una compilación terminada, el envío de un formulario — sin bloquearse esperando el tiempo de respuesta del receptor.

Qué ves cuando termina

Cada intento queda registrado con su estado HTTP, latencia y un extracto del cuerpo de respuesta, así que una entrega fallida no es un misterio: obtiene el mismo detalle que hubiera mostrado un comando curl. El estado final, exitoso o en cola de fallos, llega mediante su propio webhook firmado o un enlace firmado válido por 24 horas, según lo que hayas configurado para los resultados de este endpoint.