¿Puedo probar un webhook sin exponer mi máquina local?

Sí, ese es el punto de un receptor mock. El proveedor llama a una URL pública que no es tu computadora portátil.

¿Veré los encabezados de firma que envía el proveedor?

Sí. El inspector registra las cabeceras de cada entrega, incluidas las cabeceras de firma del proveedor como Stripe-Signature y X-Hub-Signature-256. Las cabeceras con credenciales como Authorization, Cookie y X-Api-Key se guardan censuradas, y de una cabecera repetida solo se conserva el primer valor. Verificar una firma sigue siendo tarea de tu handler: el mock acepta lo que llegue.

¿Puede el endpoint responder con un valor tomado de la solicitud?

Sí. Los tokens de petición permiten que la respuesta haga eco de parte del cuerpo entrante, que es justo lo que exigen handshakes como el url_verification de Slack antes de habilitar un endpoint.

Probar un receptor de webhook

Captura llamadas de webhook entrantes e inspecciona sus encabezados y cuerpo en tiempo real.

Para probar un receptor de webhooks necesitas una URL pública a la que el remitente pueda llegar de verdad, lo que descarta localhost. Un endpoint de webhook simulado te da esa URL al instante: acepta el POST, devuelve la confirmación que el proveedor espera y registra la petición completa, de modo que puedas leer las cabeceras y el cuerpo que el remitente transmitió realmente, y no los que dice la documentación.

¿Por qué el proveedor no puede simplemente llamar a localhost?

Un webhook es el servidor del proveedor llamando al tuyo. http://localhost:3000 significa «esta máquina» también del lado del proveedor, así que su llamada nunca sale de su red. Las herramientas de túnel lo resuelven exponiendo tu portátil; un endpoint simulado lo resuelve sacando tu portátil del circuito por completo.

Esa diferencia importa al principio. Antes de que exista tu handler, lo que necesitas saber es qué envía el proveedor: qué cabeceras, qué cuerpo, qué tipo de contenido. Un mock responde a esa pregunta en una sola entrega, y escribes el handler contra la petición registrada en vez de contra el ejemplo de la documentación.

¿Qué debería responder el endpoint al remitente?

Casi todos los proveedores tratan cualquier 2xx como éxito y todo lo demás como un fallo que merece reintento, así que devuelve 200 rápido y mantén el cuerpo pequeño. Stripe reintenta durante días ante un no-2xx; GitHub anota el fallo en el registro de entregas. Ambos castigan a un handler lento con la misma dureza que a uno roto.

Algunos proveedores quieren algo más que un código de estado. La Events API de Slack no habilita un endpoint hasta que este devuelve el valor challenge de la petición de verificación. Si tu endpoint tiene que responder con algo derivado de la petición, simula ese eco en lugar de un cuerpo fijo.

¿Cómo ves lo que el remitente realmente envió?

Abre el inspector del mock y verás cada entrega con su método, cabeceras, cuerpo y marca de tiempo. Esta es la parte difícil de conseguir de cualquier otra forma: las cabeceras de firma, el tipo de contenido exacto y la diferencia entre lo que el proveedor documenta y lo que realmente transmite.

Dispara un evento real desde el panel del proveedor en lugar de enviarte un POST escrito a mano. Un payload que has escrito tú confirma tus suposiciones; un payload que ha enviado el proveedor las corrige.

Merece la pena comparar dos entregas del mismo evento una al lado de la otra. Los proveedores reenvían tras un fallo, y el reintento no siempre es idéntico byte a byte al primer intento: si el proveedor envía una cabecera con el identificador de entrega, es de ahí de donde debe salir tu clave de idempotencia, y no de un hash del cuerpo.

¿Qué suele salir mal?

Probar con un payload que inventaste. Demuestra que tu analizador maneja tu propio JSON, lo cual nunca estuvo en duda.
Devolver 200 antes de que el trabajo esté hecho, o después. Reconoce rápido, luego procesa asíncronamente.
Ignorar la reentrega. Los reintentos significan que el mismo evento llega dos veces. Los controladores deben ser idempotentes.
Asumir que el mock verifica firmas. No lo hace. La verificación de firmas es el trabajo de tu controlador.

Cuándo usar esto

Integrar un webhook de terceros (Stripe, GitHub, una pasarela de pago) significa que necesitas una URL a la que apuntarlo, y una forma de ver exactamente qué envía. Crea un mock POST, dale su URL al proveedor y observa cómo aterriza cada llamada en el inspector de peticiones en vivo: método, cabeceras, query y cuerpo.

Crear el mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "POST",
  "response_status": 200,
  "response_body": "{\"received\":true}"
}'

Llamarlo

curl -X POST -H 'Content-Type: application/json' -d '{"event":"payment.succeeded"}' https://quickmock.dev/m/<slug>

Abre la página del mock y pega su token de administrador para ver el método, los encabezados, la consulta y el cuerpo en el inspector privado en vivo.

Lo que obtienes

{"received":true}

Preguntas frecuentes

¿Puedo probar un webhook sin exponer mi máquina local?: Sí, ese es el punto de un receptor mock. El proveedor llama a una URL pública que no es tu computadora portátil.
¿Veré los encabezados de firma que envía el proveedor?: Sí. El inspector registra las cabeceras de cada entrega, incluidas las cabeceras de firma del proveedor como Stripe-Signature y X-Hub-Signature-256. Las cabeceras con credenciales como Authorization, Cookie y X-Api-Key se guardan censuradas, y de una cabecera repetida solo se conserva el primer valor. Verificar una firma sigue siendo tarea de tu handler: el mock acepta lo que llegue.
¿Puede el endpoint responder con un valor tomado de la solicitud?: Sí. Los tokens de petición permiten que la respuesta haga eco de parte del cuerpo entrante, que es justo lo que exigen handshakes como el url_verification de Slack antes de habilitar un endpoint.

Construye el tuyo propio

Crear un mock

Plantillas listas para usar para esto: Simular un payload de webhook de Stripe, Simular un webhook de pedido de Shopify, Simular un webhook push de GitHub

Guías relacionadas

← Todas las guías

Última actualización: 2026-10-17