Zoom Team Chat reply fails, but sending new messages works

Questions
1

Hi, I’m using n8n HTTP Request nodes to reply to Zoom Team Chat messages.

  • Receiving @mentions and sending new messages both work.
  • Chatbot API (POST /v2/im/chat/messages) with reply_to returns 201, but the reply is invisible under the original user message.
  • User API (POST /v2/chat/users/{userId}/messages) with reply_main_message_id returns 400 / 5401: Message does not exist.
  • This also happens when replying to a message just created by the same user API: the new message is visible in Zoom, but its returned ID cannot be used for Reply.
  • Replying manually through the Zoom client works.

OAuth permissions have been checked and reauthorized. Has anyone encountered this, or found a working n8n configuration for replying within the original Zoom message thread?

2

Hi @Ops_Silenlinss, for the message you just created with the user API, first check whether Zoom can read it back: GET https://api.zoom.us/v2/chat/users/{userId}/messages/{messageId}, using its returned id, the same credential, and the original to_channel or to_contact as a query parameter. Use me for a user-level app.

Please share its HTTP status/body and the resolved JSON bodies for the successful send and failed reply, with tokens removed and IDs anonymized consistently. If GET also cannot find the message, the failure already occurs at message lookup; if it succeeds, we can compare the recipient and reply_main_message_id in the reply request.

There’s also an unresolved report on Zoom’s community of the chatbot returning 201 with an invisible reply, including with direct API calls outside n8n:

3

We completed the exact single-message GET, and it also returns 400 / 5401.

Same OAuth app, user, credential and channel throughout. We reauthorized the credential with the required single-message read scope before GET. This is an admin-managed app, so we used the explicit user ID.

IDs below are anonymized consistently.

1. Create — HTTP 201; message visible in Zoom

POST /v2/chat/users/USER_A/messages

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

Response:

{"id":"MESSAGE_A"}

2. Exact GET — HTTP 400

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

Response:

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

3. Reply — HTTP 400

POST /v2/chat/users/USER_A/messages

Resolved body:

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

Response:

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

An immediate reply and a retry approximately 47 seconds later both failed. The exact GET also failed several hours later.

This confirms message lookup fails even for a visible message created by the same API. Is there a known prerequisite or workaround for this behavior?

Also, the Zoom Community report you linked is our own report.

4

5401 on that GET puts the failure at message lookup, before reply threading. I don’t have a verified workaround for that exact result. And thanks for clarifying that the linked Zoom report is yours.

I’d take this create → GET → reply example to Zoom Developer Support. On diagnostic copies of the HTTP Request nodes, enable Options → Response → Include Response Headers and Status, plus Never Error, to capture headers from the 400 responses. Record x-zm-trackingid and the UTC timestamp for each call, then share those and the real user/channel/message IDs privately with Zoom support. Ask them to trace why the ID returned by the successful create cannot be resolved by GET.