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

🧪 Ejemplo: Qué hacer si la información no llegó a Zapier

1. 📤 Revisar la URL de la petición HTTP en Atom

   Verifica que solo tenga una dirección válida. Evita concatenaciones accidentales.

2. 🧪 Simular el flujo

   Desde Atom, prueba el flujo asegurando que la condición que activa la petición se cumpla.

3. 🕵️ 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.

4. 🔁 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

• Utiliza Postman o 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?

1. Revisa los logs de la conversación

   • Desde el historial de conversación, verificá si el paso de la petición HTTP fue ejecutado.

   • Si el campo aparece vacío (null o ""), significa que no fue capturado previamente o fue sobrescrito.

2. 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.

   • Para campos del sistema como telefono, evitá sobrescribirlos con otros valores en el flujo.

3. Chequea el nombre exacto del campo en la petición HTTP

   • ¿Utilizas telefono, teléfono, telefono_usuario?

   • 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?

• 🧩 ¿Los nombres de los campos en el cuerpo del HTTP coinciden con los del flujo?

• 🧪 ¿Se hicieron pruebas reales tras los cambios?

• 🧠 ¿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).

• Evita sobrescribir campos de sistema a menos que sea estrictamente necesario.

• Simula siempre el flujo para verificar si el dato fue capturado correctamente.

• Verifica los logs en cada cambio estructural antes de lanzar una campaña o automatización.

• 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

• Se active un error silencioso en la ejecución

• 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 tipo boolean (true / false) pero el campo del flujo está preparado para guardar una cadena 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ón Gestionar errores dentro del componente Petición HTTP, que te permite:

• Verificar si la API devuelve un tipo distinto al esperado.

• Aplicar una condición para transformar el valor antes de guardarlo.

• 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:

1. Crear un componente “Guardar campo” con una condición:

   • Si puedePagar es true, guardar "Sí"

   • Si puedePagar es false, guardar "No"

2. O directamente transformar el dato en la lógica de la API, si es posible.

🧪 Recomendaciones antes de testear

💡 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