Webhook Tester

Hook eliminado. La URL ya no acepta solicitudes y todo lo que capturó ha desaparecido.

Qué almacena este servicio — y qué no hace nunca

Crear un hook almacena, en el servidor de comprobación de SysOSX, solo el id del hook, sus horas de creación y caducidad y la dirección que lo creó. Cada solicitud capturada guarda la hora de llegada, el método, la ruta con su cadena de consulta, las cabeceras tal como se enviaron, el cuerpo hasta 256 KB (lo que lo supere se trunca y se marca) y la dirección del remitente. Un hook guarda como máximo 50 solicitudes; las entregas posteriores se rechazan hasta que caduca. Todo se elimina 30 minutos después de crear el hook, o inmediatamente cuando pulsas el botón de eliminar. El receptor solo recibe: nunca obtiene, sigue ni repite nada — una solicitud capturada no provoca ninguna llamada saliente. Para la herramienta de depuración vecina, consulta el trazador de cadenas de estado HTTP, y para el flujo completo lee depurar webhooks sin la fontanería.

Por qué depurar webhooks es incómodo sin un receptor

Un webhook es el servidor de otro llamando al tuyo, según su horario, en respuesta a un evento que no controlas: un pago que se completa, un push que llega, una alerta que se dispara. Esa forma es lo que hace que los webhooks sean difíciles de depurar. El remitente no puede llegar a tu portátil, así que el desarrollo local necesita un túnel o una máquina pública de staging antes de ver una sola entrega real; el evento puede ser difícil de disparar dos veces, así que la única entrega que consigas más vale que se capture completa; y cuando algo falla, el panel del remitente suele mostrar solo el código de estado que devolvió tu endpoint, no lo que realmente envió. ¿Estaba la cabecera de firma? ¿Era el cuerpo la forma JSON que prometía la documentación, o venía codificado como formulario? ¿El reintento envió el mismo id de evento? Ninguna de esas preguntas puede responderse solo con los registros de tu manejador si este rechazó la solicitud antes de registrarla — que es exactamente lo que ocurre con los errores de firma y de análisis que dominan la depuración de webhooks.

Un receptor temporal elimina la fontanería de ese ciclo. En lugar de desplegar un manejador a medio escribir solo para ver qué llega, creas una dirección que lo acepta todo, lo registra fielmente y te lo muestra: las cabeceras en el orden y la capitalización en que llegaron, el cuerpo sin procesar antes de que ningún analizador haya podido rechazarlo, la cadena de consulta en la que los remitentes a veces esconden parámetros, y el método exacto — porque algunos proveedores entregan con POST, otros con PUT, y unos pocos comprueban el estado con GET. Con una entrega real capturada en pantalla puedes escribir tu manejador contra la verdad en lugar de contra la documentación, construir un fixture para tus pruebas a partir de la carga real y comparar un reintento fallido con el original lado a lado. Después eliminas el hook, apuntas el proveedor a tu endpoint real y disparas el evento una vez más para ver a tu propio manejador responderlo. Treinta minutos es deliberadamente corto: suficiente para una sesión de depuración, y corto para que una dirección de prueba olvidada y llena de cargas capturadas no se quede rondando por internet.

Preguntas frecuentes