ZCC PATCH engagement API always returns 7001 Invalid engagement_status — transfer/update impossible despite correct scopes and privileges

API and Webhooks Contact Center
1

We are attempting to use the documented Zoom Contact Center engagement update/transfer functionality:

PATCH /v2/contact_center/engagements/{engagementId}

Specifically:

{
  "engagement_action": "transfer to queue",
  "target_queue_id": "<valid_queue_id>"
}

The response is consistently:

{
  "code": 7001,
  "message": "Invalid engagement_status."
}

We have reproduced this with multiple fresh, active voice engagements, including a completely standard inbound voice engagement currently sitting in a native ZCC queue with status: in_queue.

Authorization/configuration already verified:

  • Server-to-Server OAuth
  • The issued token explicitly contains: contact_center:update:engagement:admin
  • S2S app owner is a Contact Center Admin
  • The Admin role privilege list explicitly contains: EngagementTransfer
  • The Contact Center UI shows Transfer engagements enabled
  • Source queue policy allows transfers
  • GET /v2/contact_center/engagements/{engagementId}/transfer/queues succeeds for the same engagement and returns the intended destination queue

Zoom documents contact_center:update:engagement:admin as the granular scope for Update an engagement.

Zoom’s March 23, 2026 Contact Center API release explicitly added:

  • engagement_action
  • target_agent_id
  • target_flow_id
  • target_queue_id

to:

PATCH /v2/contact_center/engagements/{engagementId}

and simultaneously added the /transfer/queues, /transfer/users, and /transfer/flows discovery endpoints.

We also performed two diagnostic PATCH requests on separate disposable live engagements:

{
  "engagement_status": "end"
}

and:

{
  "engagement_action": "end"
}

Both return exactly the same:

{
  "code": 7001,
  "message": "Invalid engagement_status."
}

This therefore does not appear to be specific to transfer-to-queue.

We have also reproduced the transfer failure with engagements in both: in_queue and assigned states.

Support history

We first opened a Zoom Developer Support case. Developer Support reviewed it and closed the case stating:

“We have confirmed this issue is configuration-related and not within the scope of your account’s Developer Support Plan.”

We then opened a Zoom Contact Center Technical Support case under Settings and Configuration, referencing the Developer case.

Contact Center Support confirmed that the S2S app owner is a Contact Center Admin and then closed that case, directing us back to the Developer Forum.

We have therefore exhausted the customer-visible OAuth, role, and queue configuration we can identify.

Questions for Zoom engineering:

  1. Is there an additional account entitlement or backend feature flag required for the engagement-action functionality added in March 2026?
  2. Is PATCH /contact_center/engagements/{id} expected to support active voice engagements in in_queue status?
  3. Is 7001 Invalid engagement_status expected from this API? If so, which exact engagement_status values are valid?
  4. Why does /transfer/queues successfully return valid destinations for the same engagement while the PATCH transfer operation fails?
  5. Could our account/cluster be running a PATCH implementation that does not have the newer engagement-action functionality enabled?

I can provide current engagement IDs, timestamps, full response headers, x-zm-trackingid, cci-trace-id, and zm-cube-traceid from fresh reproductions privately if a Zoom engineer wants to trace this internally.