Skip to main content
Question

External Request a OpenAI envía {{cuf_XXXXX}} sin resolver en producción (nunca falla en Test Request)

  • August 26, 2026
  • 3 comments
  • 5 views

anderson ortega

Hola, tengo un problema recurrente con una automatización que usa un bloque de Solicitud Externa (External Request) hacia api.openai.com/v1/chat/completions.

El problema: cuando la solicitud se ejecuta en el flujo real (con clientes reales, en vivo), varios de los campos personalizados que inserto dentro del "Cuerpo" de la solicitud (usando la sintaxis {campo}) no se resuelven a su valor de texto -- en su lugar, se envían literalmente como "{{cuf_XXXXXXX}}" (el ID interno del campo), lo cual rompe el JSON y genera el error "Invalid payload json" en Configuración > Registros.

Detalles importantes:
- Le pasa a más de un campo personalizado (confirmado con dos campos distintos: uno de tipo Texto usado para acumular mensajes, y otro usado para el historial de conversación).
- El ID del campo en el error SIEMPRE coincide con el ID real y correcto del campo (confirmé esto en Configuración > Fields), así que no es un campo duplicado ni mal identificado.
- El error es 100% consistente en producción: cada vez que un cliente responde después del primer mensaje de la conversación, la solicitud falla de esta forma.
- Cuando uso el botón "Probar Solicitud" dentro del editor de la Solicitud Externa (con datos ya guardados manualmente en el contacto de prueba), la solicitud SIEMPRE funciona perfecto y trae la respuesta real de OpenAI -- el problema nunca se reproduce en la prueba manual, solo en el flujo real con clientes.
- Ya revisé y descarté: el Mapeo de Respuesta está bien configurado (choices[0].message.content -> mi campo respuesta_ia), no hay timeout (uso openai.com, que tiene timeout extendido), y los campos personalizados tienen valores guardados correctamente justo antes de esta solicitud (lo confirmé con un campo de diagnóstico adicional).

Mi sospecha es que la Solicitud Externa está usando una versión desactualizada ("caché" o snapshot) de los datos del contacto en el momento de construir el payload, en vez de leer el valor recién guardado en los pasos anteriores del mismo flujo.

¿Es esto un problema conocido? ¿Hay alguna forma de forzar que la Solicitud Externa use los valores más recientes de los campos del contacto?

Gracias de antemano.

3 replies

Gustavo Boregio
Forum|alt.badge.img+7
  • Community Moderator & Expert
  • August 26, 2026

Manychat pone valores del estilo de ‘{{cuf_XXXXXXX}}’ cuando el campo está vacío.

Chequea que esos campos tengan un valor correspondiente al momento de hacer el request.

Si debido a tu lógica pueden llegar en blanco, configura un valor por defecto.

Con esto deberías poder resolver este problema.


anderson ortega

Manychat pone valores del estilo de ‘{{cuf_XXXXXXX}}’ cuando el campo está vacío.

Chequea que esos campos tengan un valor correspondiente al momento de hacer el request.

Si debido a tu lógica pueden llegar en blanco, configura un valor por defecto.

Con esto deberías poder resolver este problema.

Gracias Gustavo. Ya había revisado esa posibilidad, pero en mi caso el campo NO estaba vacío en el momento del request -- lo confirmé agregando un campo de diagnóstico (debug_check) que copia el valor de mensajes_pendientes justo un paso antes de llamar a OpenAI, y en el log de la conversación se ve claramente que el campo tenía un valor real guardado (no vacío) apenas segundos antes de que fallara con el {{cuf_XXXXXX}}.

También probé configurando un valor por defecto (un guión "-") mediante un paso de "Establecer campo de usuario" justo antes del request, y el error sigue ocurriendo con el mismo patrón.

¿Es posible que sea un tema de timing interno -- que el valor recién escrito por un paso anterior (Establecer campo de usuario) no esté disponible todavía para el módulo de External Request, aunque venga después en la secuencia del flujo, incluso con una Pausa Inteligente de por medio? ¿Hay alguna forma de forzar que el request espere a que el campo esté "confirmado" antes de leerlo?


Gustavo Boregio
Forum|alt.badge.img+7
  • Community Moderator & Expert
  • August 27, 2026

@anderson ortega no debería. Si está bien configurado, el tema del timing no tiene que existir.

La otra posibilidad es que sea algún otro error, y que en el log de Manychat muestre el {{cuf_xxx}}.

Esto también suele pasar.

Si querés comparti una captura de tu automatización que le pegamos una mirada ;)