La respuesta en Zoom Team Chat falla, pero enviar nuevos mensajes funciona

Preguntas
1

Hola, estoy usando nodos HTTP Request de n8n para responder a mensajes de Zoom Team Chat.

  • Recibir @mentions y enviar mensajes nuevos funcionan.
  • La API de Chatbot (POST /v2/im/chat/messages) con reply_to devuelve 201, pero la respuesta es invisible bajo el mensaje del usuario original.
  • La API de Usuario (POST /v2/chat/users/{userId}/messages) con reply_main_message_id devuelve 400 / 5401: Message does not exist.
  • Esto también ocurre al responder a un mensaje recién creado por la misma API de Usuario: el mensaje nuevo es visible en Zoom, pero su ID devuelto no se puede usar para Reply.
  • Responder manualmente a través del cliente de Zoom funciona.

Los permisos de OAuth han sido verificados y reautorizados. ¿Alguien ha encontrado este problema o ha encontrado una configuración de n8n funcional para responder dentro del hilo de mensajes original de Zoom?

2

Hola @Ops_Silenlinss, para el mensaje que acabas de crear con la API de usuario, primero verifica si Zoom puede leerlo de vuelta: GET https://api.zoom.us/v2/chat/users/{userId}/messages/{messageId}, usando su id devuelto, la misma credencial, y el to_channel o to_contact original como parámetro de consulta. Usa me para una aplicación a nivel de usuario.

Por favor, comparte su estado HTTP/cuerpo y los cuerpos JSON resueltos para el envío exitoso y la respuesta fallida, con tokens eliminados e IDs anonimizados consistentemente. Si GET tampoco puede encontrar el mensaje, el error ya ocurre en la búsqueda de mensajes; si tiene éxito, podemos comparar el destinatario y reply_main_message_id en la solicitud de respuesta.

También hay un informe sin resolver en la comunidad de Zoom del chatbot devolviendo 201 con una respuesta invisible, incluyendo llamadas API directas fuera de n8n:

3

Completamos el GET exacto de un único mensaje, y también devuelve 400 / 5401.

Misma aplicación OAuth, usuario, credencial y canal en todo momento. Reautorizamos la credencial con el alcance de lectura de mensaje único requerido antes del GET. Esta es una aplicación administrada, por lo que utilizamos el ID de usuario explícito.

Los IDs que aparecen a continuación están anonimizados de forma consistente.

1. Crear — HTTP 201; mensaje visible en Zoom

POST /v2/chat/users/USER_A/messages

{
  "message": "User API thread control - diagnostic test",
  "to_channel": "CHANNEL_A"
}

Respuesta:

{"id":"MESSAGE_A"}

2. GET exacto — HTTP 400

GET /v2/chat/users/USER_A/messages/MESSAGE_A?to_channel=CHANNEL_A

Respuesta:

{"code":5401,"message":"Message does not exist: MESSAGE_A."}

3. Respuesta — HTTP 400

POST /v2/chat/users/USER_A/messages

Cuerpo resuelto:

{
  "message": "pong (user-api parent control)",
  "to_channel": "CHANNEL_A",
  "reply_main_message_id": "MESSAGE_A"
}

Respuesta:

{"code":5401,"message":"Message does not exist: MESSAGE_A."}

Una respuesta inmediata y un reintento aproximadamente 47 segundos después fallaron. El GET exacto también falló varias horas después.

Esto confirma que la búsqueda de mensaje falla incluso para un mensaje visible creado por la misma API. ¿Hay algún requisito previo conocido o una solución alternativa para este comportamiento?

Además, el informe de la Comunidad Zoom que vinculaste es nuestro propio informe.

4

5401 en ese GET sitúa el fallo en la búsqueda de mensajes, antes del enhebrado de respuestas. No tengo una solución verificada para ese resultado exacto. Y gracias por aclarar que el informe de Zoom vinculado es tuyo.

Llevaría este ejemplo create → GET → reply a Zoom Developer Support. En copias de diagnóstico de los nodos HTTP Request, habilita Opciones → Respuesta → Incluir encabezados de respuesta y estado, además de Never Error (Nunca error), para capturar encabezados de las respuestas 400. Registra x-zm-trackingid y la marca de tiempo UTC para cada llamada, luego comparte esos datos y los ID reales de usuario/canal/mensaje de forma privada con el soporte de Zoom. Pídeles que rastreen por qué el ID devuelto por la creación exitosa no puede ser resuelto por GET.