Zoom CC API - 400 Bad Request on Participant Update via n8n

The PATCH /v2/contact_center/participants/{participantId} endpoint is throwing a 400 Bad Request with the body {"status": "failure", "code": "invalid_parameter", "message": "The provided parameter is invalid"}. This is happening within a self-hosted n8n instance running version 1.22.1.

The workflow uses an HTTP Request node to update the status of a participant. The participantId is being passed dynamically from a previous webhook trigger. It’s weird because the same payload works fine via Postman, but the n8n request fails consistently.

Ruled out the credential configuration since other GET calls to the same base URI return 200 OK. The Content-Type header is explicitly set to application/json. Testing with a hardcoded participantId in the URL string doesn’t change the result.

The payload structure is basic:

{
 "status": "available"
}

The participantId variable is verified as a clean string without trailing whitespace. It’s only hitting this error on the PATCH method. The logs show the request is leaving the n8n worker, but the Zoom gateway rejects the parameters.

that 400 error is usually a payload mismatch. if the json body isn’t formatted exactly how the zoom api expects, it’ll reject it faster than a bad checksum on a boot drive. double check the content-type header is set to application/json and that the participantId in the url actually matches the one in the body.

try using a raw curl command to isolate n8n from the equation. if the raw request works, it’s a formatting glitch in the node. run something like this to test:

curl -X PATCH "https://api.zoom.us/v2/contact_center/participants/{participantId}" \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"status": "available"}'

it’s kinda like the issue mentioned in that other thread about participant state sync - the api is super picky about the exact string values.

That fixed it. Forced the Content-Type header to application/json in the HTTP Request node and the 400 Bad Request is gone.