PATCH /phone/auto_receptionists/{id}/ivr returns 204 but doesn't persist any changes

Environment

• Zoom Phone
• Server-to-Server OAuth app, all phone:*:auto_receptionist*:admin scopes granted 
• Calling the REST API directly over HTTPS (Python urllib), no SDK
• Authenticated via account-credentials grant; bearer token verified valid via GET calls on the same endpoint

What I'm trying to do Configure the IVR menu on an Auto Receptionist programmatically — set the audio_prompt and define key_actions so that pressing 1, 2, 3, 4, etc. routes the caller to specific users, a call queue, or another Auto Receptionist. I'd like to manage this from code rather than clicking through zoom.us every time.

What's going wrong PATCH /v2/phone/auto_receptionists/{autoReceptionistId}/ivr returns HTTP 204 with an empty body. A subsequent GET /v2/phone/auto_receptionists/{autoReceptionistId}/ivr shows the IVR completely unchanged. The same ?hours_type=business_hours query parameter behaves identically — 204, no persistence.

This reproduces across many payload variants:

• Single-key updates (just one entry in key_actions)
• Full-replacement payloads with the entire key_actions array
• Every documented value of key_actions[].action (1, 2, 3, 4, 6, 7, 21, 100, 200)
• Updates that only change audio_prompt
• With and without the hours_type query parameter

None persist. GET consistently returns the prior state.

Evidence the request body IS being parsed Sending an invalid value — caller_enters_no_action.action: 21 — returned a real validation error:

HTTP 400 — "The action value set for if caller enters no action after the prompt played is not correct."

So the server is parsing the body and validating fields. It just silently no-ops on payloads that pass validation.

Troubleshooting already done

• Confirmed the bearer token is valid: GET on the same endpoint, and GET /phone/auto_receptionists, both return correct data
• Confirmed scopes are correct: scope list includes phone:write:auto_receptionist_ivr:admin and related
• Refreshed the OAuth token and retried — same result
• Tried both with and without ?hours_type=business_hours
• Tried Content-Type: application/json (default) and confirmed the request body is being received (validation errors fire correctly)
• Tried PATCHing through /phone/extension/{ext}/call_handling/settings/{settingType} instead — same silent no-op behavior on AR settings
• Configuring the identical IVR through the web admin UI works correctly, and the new state is then visible via GET on the API — so the data path is fine, only programmatic writes are silently dropped

Sample response headers from a no-op PATCH (in case they help trace the request):

• zm-cube-traceid: fec3f9d3e76e740e4750f0ebcf1eb8cd
• x-zm-trackingid: WEB_5516d382133d6a589a48e7e823a95074
• Region: x-zm-region: VA

Has anyone else seen this? Is there a known restriction on programmatic IVR writes for certain Phone tiers, or is this a bug? Either way, the silent 204 is misleading — if writes are blocked, an error would help.

Thanks.