Demote participants from admin
POST/api/sessions/:sessionId/groups/:groupId/participants/demote
Demote participants from admin
Request
Responses
- 200
- 400
- 403
- 409
- 503
Participants processed — results carries the per-participant outcome (a partial refusal does not fail the batch; a total refusal is an error)
A participant does not name an individual. Pass a phone number, <phone>@c.us or <lid>@lid; a group id or free text is rejected.
WhatsApp refused the operation. The request was well formed — the refusal happened WhatsApp-side, most often because the account lacks the admin rights the operation requires.
The session is not connected — an engine exists for it but is not ready: disconnected, reconnecting, or still initializing, so the request never reached WhatsApp. Wait for ready and retry. A session that was never started answers 400 instead, and the session lifecycle routes answer 409 for a conflicting state rather than this. One window answers this while the session still reads ready: WhatsApp Web periodically reloads its own page and the engine re-injects into it — for those few seconds the answer is a 409 naming the reload; retry shortly.
WhatsApp did not answer within the request budget, so no per-participant outcome was read at all. Deliberately not folded into the 200 above — a participant WhatsApp turned down is reported inside results and is an answer; an update that never came back is not.