Every SMS send via POST /phone/sms/messages returns error 7639 even though the number is user-owned, SMS-enabled, and on an active 10DLC campaign

Phone
, ,
1

I’m getting error 7639 “The SMS for the number does not belong to the current user.” on every SMS send via POST /v2/phone/sms/messages, from a Server-to-Server OAuth app. I’ve verified every prerequisite via Zoom’s own API and tested multiple request-body shapes — all rejected identically. Looking for help confirming whether this is account-side SMS API provisioning.

SETUP
• Server-to-Server OAuth app
• Sending as user rob@[redacted], from +1 732-800-4013
• Zoom Phone metered plan

VERIFIED VIA API (all from Zoom’s own responses):

  1. Number is assigned to the sending user — GET /phone/users/{user} returns:
    “phone_numbers”: [{ “number”: “+17328004013” }]
  2. SMS policy enabled — same object: “policy”: { “sms”: { “enable”: true, “locked”: false } }
  3. It’s the user’s DIRECT number (not a shared line / auto receptionist / call queue) — GET /phone/users/{user}/settings shows it as “Direct number”, is_default: true, and primary_number.
  4. 10DLC brand + campaign ACTIVE, and this number is assigned to the campaign (Campaign ID C3L7ABZ).
  5. User is active with a US/CA Unlimited Calling Plan.
  6. Number has been stably assigned to this user for 4+ months. I also did a clean unassign → verify-unassigned → reassign cycle per support’s suggestion — no change.
    SEND ATTEMPTS — all return the same 7639:
    • sender: { user_id: , phone_number: “+17328004013” } → 7639
    • sender: { user_id: <phone_user_id>, phone_number: “+17328004013” } → 7639
    • sender: { phone_number: “+17328004013” } (no user_id) → 7639
    • sender: { id: , phone_number: “+17328004013” } → 7639
    • POST /accounts/{accountId}/phone/sms/messages → 404 (endpoint not found)

SCOPES
The phone_sms:write / phone_sms:write:admin scopes do NOT appear in the S2S OAuth scope picker at all — only read scopes. Per a Zoom staff reply on this forum, the granular read scopes (phone:read:sms_message:admin) are the current way to call the POST endpoint. I have those granted — and still get 7639.

MY QUESTION
Since the number is owned by the sending user, SMS-enabled, on an active campaign, and every valid body shape returns the identical 7639 — is API-based SMS SENDING actually provisioned on this account? Is 7639 a known symptom of the account not being enabled for SMS API sending even when the number/policy/campaign all check out? Technical Support closed my ticket saying it’s “configuration-related” and out of scope, and pointed me here.

Happy to share the full API responses (user object, settings, campaign assignment, all send attempts with verbatim errors). Anything I’m missing, or is this an account-side enablement that needs Zoom to flip?