🧠 Introducción
Las peticiones HTTP permiten conectar tu bot con servicios externos como CRMs, sistemas internos o plataformas como Zapier. Sin embargo, una mala configuración puede hacer que estos datos nunca lleguen al destino… ¡y sin aviso!
Este artículo te ayudará a identificar y resolver los errores más comunes al usar este componente.
🧨 Errores frecuentes al usar el componente HTTP
🔗 Doble inclusión de URLs: Ocurre cuando se concatena dos veces la dirección (ej.
https://https://hooks.zapier.../). Cómo prevenirlo: Revisa que la URL no tenga duplicaciones al copiar/pegar. Siempre debe empezar por un solohttps://.❌ URL inválida o mal copiada: El flujo no envía nada, ni siquiera muestra error. Cómo prevenirlo: Pega la URL en tu navegador para validar el formato o usa herramientas como Postman.
🛑 No se activa el componente HTTP: El usuario nunca llega a esa parte del flujo porque no se cumplen las condiciones previas. Cómo prevenirlo: Revisa la lógica del diseño del flujo y simula una conversación para asegurar que la ruta se active.
🔇 Error silencioso en Zapier: Zapier no registra la entrada, pero tampoco arroja un error visible en Atom. Cómo prevenirlo: Comprueba si el webhook está bien configurado revisando los requests recibidos en el historial de tareas de Zapier.
🧪 ¿Qué hacer si la información no llegó a Zapier?
Si tienes dudas de por qué falló la conexión, sigue estos pasos:
📤 Revisar la URL en Atom: Verifica que solo tenga una dirección válida y evita concatenaciones accidentales.
🧪 Simular el flujo: Desde Atom, prueba el flujo asegurando que la condición que activa la petición HTTP realmente se cumpla.
🕵️ Verificar los logs de la conversación: Ingresa al chat desde el módulo de Reportería o Historial y revisa si el paso del componente HTTP figura como ejecutado.
🔁 Revisar el historial de tareas en Zapier: Ingresa a Zapier > Zaps > Task History. Si no hay rastro del webhook, el problema está del lado de la configuración en Atom.
🔎 Campos del sistema vacíos: Cómo detectarlo
A veces, aunque el componente HTTP se ejecute correctamente, los sistemas externos no reciben valores clave como el número de teléfono, nombre o correo. Esto suele deberse a una falla silenciosa en la captura de campos.
¿Cómo identificar si el campo no fue enviado?
Revisa los logs: Si en el historial de la conversación el campo aparece vacío (
nullo""), significa que no fue capturado previamente o fue sobrescrito.Confirma el guardado: Si usas el componente Guardar campo, valida que el valor esté poblado antes del paso de integración. Evita sobrescribir campos del sistema como
telefono.Chequea el nombre exacto del campo: ¿Utilizaste
telefono,teléfonootelefono_usuarioen el cuerpo del HTTP? Debe coincidir exactamente con la variable guardada en Atom. Evita tildes, espacios o mayúsculas innecesarias.
✅ Checklist si el flujo fue duplicado o editado
Si recientemente hiciste cambios en tu flujo, hazte estas preguntas:
🔁 ¿Se copiaron correctamente los componentes que capturan o guardan datos?
🧩 ¿Los nombres de las variables en el cuerpo del HTTP coinciden exactamente con los del flujo?
🧠 ¿Se mantiene el orden correcto lógico (Captura del dato → Petición HTTP)?
🧪 ¿Se hicieron pruebas reales tras los cambios?
⚠️ Errores por discrepancia de tipos de datos
En algunos casos, el bot puede recibir desde la API un tipo de dato distinto al esperado, lo que provoca que el valor no se almacene o que el flujo no continúe.
🎯 Escenario común: Boolean vs. String Una situación habitual es que el servicio devuelva un valor tipo boolean (true o false), pero el campo del flujo en Atom esté preparado para guardar una cadena de texto (string). Esto genera un error silencioso.
🛠️ ¿Cómo prevenirlo? Utiliza la opción Gestionar errores dentro del componente Petición HTTP. Esto te permite:
Verificar si la API devuelve un error o un tipo distinto.
Redirigir a otra parte del flujo en caso de falla.
📌 Ejemplo práctico de solución: Si el endpoint devuelve true/false pero necesitas texto, crea un componente Condicional o Guardar campo tras recibir el dato:
Si la respuesta es
true➡️ guardar"Sí".Si la respuesta es
false➡️ guardar"No".
🧰 Recomendaciones finales antes de testear
✅ Prueba siempre tu endpoint en Postman con los valores exactos antes de pasarlo a Atom.
🔄 Compara el resultado de la API con lo que espera recibir tu flujo.
💬 Simula la conversación completa desde Atom para validar la captura de datos.
💡 Tip adicional: Si tu flujo espera texto, asegúrate de que todas las respuestas de tu API vengan formateadas como strings (entre comillas) para evitar conflictos.
🔗 Artículo relacionado: [Cómo probar tu API en Postman]
¡Que ningún dato se quede en el camino! 🚀
Dominar la configuración y diagnóstico de peticiones HTTP te garantiza flujos robustos e integraciones impecables. Sigue estas buenas prácticas y conecta Atom con tus herramientas sin interrupciones. ✅