Looking for advice on why the PATCH request to /api/v2/conversations/conferences/{conferenceId}/participants/{participantId} fails with a 400 Bad Request when attempting to disconnect a specific participant from an active conference call. We are building a high-throughput token service that manages call states programmatically, using the Client Credentials grant type for backend-to-backend authentication. The documentation states: ‘To remove a participant from a conference, send a PATCH request with the participant’s ID and set the muted or disconnected status appropriately.’ However, our implementation consistently fails. The HTTP request is constructed as follows: curl -X PATCH https://api.mypurecloud.com/api/v2/conversations/conferences/abc-123-def/participants/xyz-789-ghi -H 'Authorization: Bearer <valid_token>' -H 'Content-Type: application/json' -d '{"disconnected": true}'. The response payload is {"code": "bad_request", "message": "invalid participant state for operation", "status": 400}. We have verified that the OAuth token is valid and has the conversation:write scope. The conference ID and participant ID are confirmed active via the GET endpoint. The participant is not currently muted, just connected. We are using the Java SDK v1.15.0 for other operations, but this specific endpoint seems to reject the JSON body. Is there a required header or specific JSON structure missing? The docs do not specify a reasonCode or additional fields for disconnection. We have also tried setting "muted": true followed by "disconnected": true in separate calls, but the first call succeeds and the second fails with the same error. This blocks our automated call routing logic. Any insights on the exact JSON payload required or known SDK bugs with this endpoint? We are in Europe/Amsterdam timezone, but latency is not an issue. The API gateway logs show the request reaching the service. We need to programmatically drop participants based on external signals. Please advise on the correct method to achieve this without manual intervention. We have checked the rate limits and are well within bounds. The token refresh logic is robust and handles 401s gracefully. This is strictly a 400 error. We suspect a mismatch between the documented behavior and the actual API implementation. Any code examples or corrected payloads would be appreciated. We are stuck on this for two days. The integration is critical for our SSO bridge monitoring dashboard. We cannot proceed until this is resolved. Please help.