Cómo detectar y solucionar errores en peticiones HTTP de tu bot
🧠 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
| Error |
| Qué ocurre |
| Cómo prevenirlo |
| Doble inclusión de URLs |
| Se concatena dos veces la dirección, como:https://hooks.zapier.../
... |
| Revisa que la URL no tenga duplicaciones al copiar/pegar. Siempre debe empezar porhttps://y no contener otrohttps://dentro |
| URL inválida o mal copiada |
| El flujo no envía nada, ni siquiera muestra error |
| Pega la URL en el navegador para validar formato o usá herramientas como Postman |
| No se activa el componente HTTP |
| El usuario no llega a esa parte del flujo por condiciones no cumplidas |
| Revisa el diseño del flujo y simulá una conversación para asegurar que se active |
| Error silencioso en Zapier |
| Zapier no registra la entrada, pero tampoco arroja error visible |
| Comprueba si el webhook está bien configurado. En Zapier, revisa los últimosrequestsrecibidos en el historial de tareas |
🧪 Ejemplo: Qué hacer si la información no llegó a Zapier
📤Revisar la URL de la petición HTTP en AtomVerifica que solo tenga una dirección válida. Evita concatenaciones accidentales.
📤Revisar la URL de la petición HTTP en Atom
Verifica que solo tenga una dirección válida. Evita concatenaciones accidentales.
🧪Simular el flujoDesde Atom, prueba el flujo asegurando que la condición que activa la petición se cumpla.
🧪Simular el flujo
Desde Atom, prueba el flujo asegurando que la condición que activa la petición se cumpla.
🕵️Verificar los logs de la conversaciónIngresa a la conversación desde el módulo de reportería o historial y revisa si el paso del componente HTTP figura.
🕵️Verificar los logs de la conversación
Ingresa a la conversación desde el módulo de reportería o historial y revisa si el paso del componente HTTP figura.
🔁Revisar el historial de tareas en ZapierIngresa a Zapier > Zaps > Task History. Si no hay rastro del webhook, el problema es del lado de Atom.
🔁Revisar el historial de tareas en Zapier
Ingresa a Zapier > Zaps > Task History. Si no hay rastro del webhook, el problema es del lado de Atom.
🛠 Recomendaciones para testear tus peticiones
UtilizaPostmano herramientas similares para validar que el endpoint responda correctamente.
Prueba manualmente el cuerpo de la petición con datos reales.
Si utilizas variables dinámicas (,), asegurate de que esas variables estén pobladas antes de activar la petición.
Agrega un paso de “mensaje de validación” antes y después del HTTP para rastrear si se ejecutó.
✅ Buenas prácticas para este escenario
No pegues URLs desde editores que puedan incluir caracteres invisibles.
Prueba cada cambio con usuarios de prueba o en una copia del flujo.
Documenta internamente cuál es la URL válida y quién la administra (útil si utilizas múltiples webhooks).
🔎 Campos del sistema que no se envían correctamente: cómo detectarlo
A veces, aunque el componente HTTP se ejecute correctamente, los sistemas externos como Zapier o tu CRM no reciben algunos valores clave como el número de teléfono, nombre o correo. Esto puede deberse a una falla silenciosa en la captura de campos del sistema.
🧪 ¿Cómo identificar si el campo no fue enviado?
Revisa los logs de la conversaciónDesde el historial de conversación, verificá si el paso de la petición HTTP fue ejecutado.Si el campo aparece vacío (nullo""), significa queno fue capturado previamenteo fue sobrescrito.
Revisa los logs de la conversación
Desde el historial de conversación, verificá si el paso de la petición HTTP fue ejecutado.
Desde el historial de conversación, verificá si el paso de la petición HTTP fue ejecutado.
Si el campo aparece vacío (nullo""), significa queno fue capturado previamenteo fue sobrescrito.
Si el campo aparece vacío (nullo""), significa queno fue capturado previamenteo fue sobrescrito.
Confirma que el dato se guardó correctamenteSi usás componentes como “Guardar campo”, validá que el valor esté poblado antes del paso de integración.Para campos del sistema comotelefono, evitá sobrescribirlos con otros valores en el flujo.
Confirma que el dato se guardó correctamente
Si usás componentes como “Guardar campo”, validá que el valor esté poblado antes del paso de integración.
Si usás componentes como “Guardar campo”, validá que el valor esté poblado antes del paso de integración.
Para campos del sistema comotelefono, evitá sobrescribirlos con otros valores en el flujo.
Para campos del sistema comotelefono, evitá sobrescribirlos con otros valores en el flujo.
Chequea el nombre exacto del campo en la petición HTTP¿Utilizastelefono,teléfono,telefono_usuario?Debe coincidir exactamente con la variable poblada en la conversación. Evita tildes, espacios o mayúsculas innecesarias.
Chequea el nombre exacto del campo en la petición HTTP
¿Utilizastelefono,teléfono,telefono_usuario?
¿Utilizastelefono,teléfono,telefono_usuario?
Debe coincidir exactamente con la variable poblada en la conversación. Evita tildes, espacios o mayúsculas innecesarias.
Debe coincidir exactamente con la variable poblada en la conversación. Evita tildes, espacios o mayúsculas innecesarias.
✅ Checklist rápida si el flujo fue duplicado o editado recientemente
🔁 ¿Se copiaron correctamente los componentes que capturan o guardan datos?
🔁 ¿Se copiaron correctamente los componentes que capturan o guardan datos?
🧩 ¿Los nombres de los campos en el cuerpo del HTTP coinciden con los del flujo?
🧩 ¿Los nombres de los campos en el cuerpo del HTTP coinciden con los del flujo?
🧪 ¿Se hicieron pruebas reales tras los cambios?
🧪 ¿Se hicieron pruebas reales tras los cambios?
🧠 ¿Se mantiene el orden correcto:captura del dato→petición HTTP?
🧠 ¿Se mantiene el orden correcto:captura del dato→petición HTTP?
🛠 Buenas prácticas para evitar este tipo de errores
Utiliza nombres de variables simples, sin espacios ni tildes(ej.telefono,email,nombre).
Utiliza nombres de variables simples, sin espacios ni tildes(ej.telefono,email,nombre).
Evita sobrescribir campos de sistema a menos que sea estrictamente necesario.
Evita sobrescribir campos de sistema a menos que sea estrictamente necesario.
Simula siempre el flujopara verificar si el dato fue capturado correctamente.
Simula siempre el flujopara verificar si el dato fue capturado correctamente.
Verifica los logs en cada cambio estructuralantes de lanzar una campaña o automatización.
Verifica los logs en cada cambio estructuralantes de lanzar una campaña o automatización.
Documenta los campos requeridos por tus integraciones externas(Zapier, CRM, etc.) para asegurar consistencia.
Documenta los campos requeridos por tus integraciones externas(Zapier, CRM, etc.) para asegurar consistencia.
⚠️ Errores por discrepancia de tipos de datos en peticiones HTTP
En algunos casos, el bot puede recibir desde la API un tipo de dato distinto al esperado en el flujo, lo que puede provocar que:
El valor no se almacene correctamente
El valor no se almacene correctamente
Se active un error silencioso en la ejecución
Se active un error silencioso en la ejecución
El flujo no continúe como se espera
El flujo no continúe como se espera
🎯 Escenario común: Boolean vs. String
Una situación habitual es que el servicio devuelve un valor tipoboolean(true/false) pero el campo del flujo está preparado para guardar unacadena de texto (string).
Error típico:
Esto puede suceder, por ejemplo, cuando se intenta guardar directamente la respuesta de la API en un campo de usuario sin hacer una validación previa o transformación.
🛠️ ¿Cómo prevenirlo?
Puedes utilizar la opciónGestionar erroresdentro del componentePetición HTTP, que te permite:
Verificar si la API devuelve un tipo distinto al esperado.
Verificar si la API devuelve un tipo distinto al esperado.
Aplicar una condición para transformar el valor antes de guardarlo.
Aplicar una condición para transformar el valor antes de guardarlo.
Redirigir a otra parte del flujo en caso de error.
Redirigir a otra parte del flujo en caso de error.
📌 Ejemplo práctico
Supongamos que el endpoint devuelve:
Pero el campo de destino en Atom espera un texto. En este caso, podrías:
Crear un componente “Guardar campo” con una condición:SipuedePagarestrue, guardar"Sí"SipuedePagaresfalse, guardar"No"
Crear un componente “Guardar campo” con una condición:
SipuedePagarestrue, guardar"Sí"
SipuedePagarestrue, guardar"Sí"
SipuedePagaresfalse, guardar"No"
SipuedePagaresfalse, guardar"No"
O directamente transformar el dato en la lógica de la API, si es posible.
O directamente transformar el dato en la lógica de la API, si es posible.
🧪 Recomendaciones antes de testear
| Paso |
| Acción |
| ✅ |
| Probar en Postman con los valores exactos |
| 🔄 |
| Comparar el resultado con lo que espera el flujo |
| 🧰 |
| Usar "Gestionar errores" en el componente Petición HTTP |
| 💬 |
| Simular la conversación completa desde Atom |
💡 Tip adicional
Si tu flujo espera valores tipo texto, asegurate que todas las respuestas que esperas guardar estén como strings (entre comillas) o mapeadas correctamente antes de ser procesadas por el bot.
📌¿Quieres validar manualmente si la información llega completa?Consulta el artículo 👉Cómo probar tu API en Postman