🔗 Probador de Webhooks IFTTT ☆

Prueba webhooks de IFTTT sin salir del navegador

Probador de Webhooks IFTTT Gratis envía una petición POST directamente a maker.ifttt.com con el nombre del evento, tu clave y hasta tres valores JSON, exactamente como espera tu applet. Sirve para depurar automatizaciones, verificar claves y confirmar que tu servicio recibe el payload.

Cómo probar un applet

• Crea un applet de Webhooks en IFTTT y copia tu clave desde la página del servicio
• Introduce el nombre del evento y tu clave arriba
• Añade value1, value3 si tu applet los usa y envía

Ten en cuenta

• La petición va directa de tu navegador a IFTTT, sin servidor intermediario
• Una prueba correcta solo significa que IFTTT aceptó el disparador; revisa el registro del applet para la acción
• Tu clave nunca se guarda ni se registra

Cómo funciona la prueba de webhook

Los webhooks de IFTTT son endpoints HTTPS simples: la clave va en la ruta y un cuerpo JSON opcional lleva hasta tres valores. El probador envía una petición real desde tu navegador (sujeta a CORS, así que la respuesta de IFTTT puede ser opaca) e informa el estado HTTP, el tiempo y la respuesta legible cuando está permitida. Un 200 confirma que la clave y el nombre del evento son válidos; 401 y 404 apuntan a una clave o un evento incorrectos. La prueba no demuestra que la acción posterior del applet se ejecutara: revisa el registro de actividad del applet.

Formatos, límites y parámetros

Privacidad: nada pasa por 0Appz

Una clave de IFTTT puede disparar automatizaciones reales, así que enviarla a un probador de terceros es un riesgo cierto. Aquí la petición sale de tu navegador directamente hacia IFTTT: la clave se escribe en la página, se usa localmente y nunca se transmite a nosotros ni se almacena.

Lista de depuración de webhooks

• Verifica que el nombre del evento coincide exactamente con el applet: distingue mayúsculas.
• Vuelve a copiar la clave desde la página de Webhooks: los espacios la rompen.
• Comprueba que el applet está conectado y activado.
• Recuerda que CORS puede ocultar la respuesta incluso con éxito; usa el registro de actividad.
• Rota la clave si alguna vez se pegó en una herramienta no confiable.

Relacionado: explora las herramientas de desarrollo para cabeceras, webhooks y depuración de API.

Webhooks, payloads y códigos de respuesta

Un webhook es solo una petición HTTP que un servicio hace a una URL que controlas, y probarlo significa reproducir esa petición con fidelidad. El método casi siempre es POST y el cuerpo suele ser JSON, así que la cabecera Content-Type debe indicar application/json o la automatización receptora puede rechazar el payload. El servicio Webhooks de IFTTT es un caso especial: acepta tres valores llamados value1, value2 y value3, que pueden enviarse como cuerpo JSON o como campos de formulario codificados en la URL. Mantenerse dentro de esos tres campos es la principal restricción de diseño, así que empaqueta datos estructurados en una sola cadena JSON dentro de value1 cuando necesites más. Los códigos de respuesta dicen qué pasó: un 200 significa que el servicio aceptó el evento, 400 suele indicar JSON mal formado o un campo ausente, 401 o 403 que la clave es incorrecta o fue revocada, y 404 que el nombre del evento no existe. Un 500 es problema del servicio, no tuyo, y reintentar la misma petición es razonable. Dos notas operativas: muchos servicios deduplican payloads idénticos, así que una prueba que envía el mismo cuerpo dos veces puede dispararse solo una, y los intermediarios de red pueden cachear o bloquear peticiones sin las cabeceras correctas. Al probar, verifica también el cuerpo de la respuesta además del código de estado, porque algunas API devuelven 200 con un objeto de error dentro.