Debajo podrás conocer las respuestas a las principales consultas frecuentes sobre la implementación de la API de mensajería y las mejores prácticas a aplicar.
| API de mensajería | |
| FAQ | Datos clave |
|
El bot responde como si fuera la primera vez, pero estoy a mitad de un flujo. |
La sesión probablemente expiró. Reiniciar el flujo con la sentence inicial. Usar siempre el mismo user.hash. |
| Recibo un HTTP 401 en todas las llamadas. | El Bearer Token expiró. Obtener un nuevo token con POST /auth y reintentar. Se recomienda cachear y renovar proactivamente. |
| El campo text viene vacío, pero hay complementos. | Es normal en algunos casos, como la lista interactiva . Renderizar los complementos como contenido principal. |
| ¿Qué hago con el value de botones tipo step? | Nunca enviarlo como sentence. En botones tipo step, siempre se envía el LABEL. |
| ¿Puedo enviar múltiples mensajes en paralelo para el mismo usuario? | No. La API es stateful. Se debe enviar siempre de forma secuencial. |
| ¿Qué pasa si el usuario cierra la app a mitad de un flujo? | La sesión queda activa hasta que expire. Si vuelve antes con el mismo hash, continúa desde donde estaba. Si expiró, debe reiniciar. |
| ¿Cómo pruebo la integración sin afectar la producción? | Solicitar a tu equipo técnico las credenciales de un ambiente de QA/testing. |
Buenas prácticas:
- Usar un hash e ID distintos para cada nueva sesión de un usuario. No reutilizar hashes entre usuarios.
- Hacer un cierre de sesión siempre (por inactividad o porque el cliente lo cerró).
- No generar un Bearer Token nuevo por cada consulta. El mismo dura 10 horas y puede reutilizarse.
- Cachear el Bearer Token y renovarlo proactivamente antes de que expire.
- No enviar mensajes en ráfaga sin throttle. Implementar debounce en el frontend para clics rápidos.
- Usar siempre el mismo hash/id durante toda la conversación.
- Implementar timeout del lado del cliente ante inactividad.
- Tolerar complementos desconocidos: ignorarlos sin romper la integración.