Sending SMS From Call Queue Through Phone API

API Endpoint(s) and/or Zoom API Event(s)
POST /v2/phone/sms/messages

Description
I am trying to send sms in a server-to-server app. The original use-case was to automatically send an sms from our marketing team to leads when a certain action is performed. After building out this logic, I found out that Zoom does not allow you to send SMS on behalf of other users. This is a serious limitation when it comes to automation (competitors offer this feature). My workaround was to instead assign that users number to a call queue and send the SMS from there. I am unable to get this working. I have created a call queue, enabled sms, assigned my number to the call queue, and assigned my user as a member to the call queue. I am also an admin on the queue if that matters. My server-to-server app has the required granular scopes.

Sample Post Body:
{

“attachments”: ,

“message”: “Testing sending a message from Zoom api”,

“sender”: {

“user_id”: “XXX…”,

“phone_number”: “+1XXXXXXXXXX”

},

“to_members”: [

{

“phone_number”: “+1XXXXXXXXXX”

}

]

}

Error:*
The post SMS api states that the sender parameter in the body has two required fields: phone_number and user_id. The description for phone_number clearly states “This must be an SMS capable phone number allocated to Zoom Phone within the customer account. Enter the number in E.164 format. This can be a phone number assigned to a user, a call queue or to the Programmatic API endpoint…”.

When I use my user_id (I am a member of the call queue) , I get the following:*
{

“code”: 7028,

“message”: “Do not allow to send SMS.”

}

When I use the call queue id as the user_id, I get:
{

“code”: 1001,

“message”: “User does not exist: XXX…”

}

When I exclude the user_id, I get:
{

“code”: 1024,

“message”: “User does not exist due to missing required params.”

}

How am I supposed to use this api with a call queue? Is the documentation just incorrect?

Hi @ebrewer
Thanks for reaching out to us.
Could you allow me some time to troubleshoot this on my end?
I am aware of the limitation when trying to send SMSs on behalf of another user and I know this is not possible. But I do not know if the workaround you are proposing should work.
So give me some time to reproduce this on my end, and will get back to you with an update.
Thanks again
Elisa

1 Like

Hi @elisa.zoom do you have an update on this? I need to know if I should create a separate solution or go with another product. Thanks.

Hi @ebrewer
Sorry for the late reply here.
From my testing, I got the same errors than you did, since the call queue is not considered a user and SMS requiere to include the sender’s user_id, this is expected.
As of right now, there is not a workaround for what you are trying to achieve

1 Like

I just wasted 2 hours trying to figure this out, not to mention the implementation time invested in using this api. Seriously - this is basic functionality. At the very least the docs should mention this is not possible. Also, in the change log here:
http-s://developers.zoom.us/changelog/phone/may-18-2025/

It mentions an endpoint “/v2/accounts/{accountId}/phone/sms/messages” which simply does not exists at the moment, I doubt it ever existed.

Hey @seidnerj
Sorry to hear you are having issues implementing this endpoint.

The endpoint “/v2/accounts/{accountId}/phone/sms/messages" mentioned in the changelog does exist, but it is only available for accounts that have a Master Account license applied.

Could you share a bit more about what you were trying to build and where you got stuck? I’d be happy to dig into this and bring your feedback to the PM.

Thank you for the clarification, I could not find this end point in the “regular” API docs, nor did I know about the concept of a Zoom “Master Account” license. I was getting a 404 http code so it seemed like this simply does not exist. At the very least, the aforementioned Change Log (and every change log really) should have a link to the appropriate place in the API docs. That alone would have saved me a lot of time as I would not have bothered trying to use such an endpoint and wondering what am I doing wrong.

I am not sure what is the difference between a non “Master Account” and a “Master Account” but I don’t think it’ll help me overcome my challenge. I’d like my users to be able to send SMS messages from their Zoom number through one of our internal applications, but I cannot send SMS messages on their behalf. Right now I’ve resorted to having them approve an internal OAuth app, then use the token I get, but this is a backend service so this does not make any sense, I keep having them authorize once every 90 days so the backend can send on their behalf. This is completely backwards.

Is there no way to send SMS messages on behalf of users with a server to server oauth app?

1 Like

Hi

Will the new Team SMS allow this with a Power Pack licence? And will the API allow messages to be sent using the Team SMS?

Thanks

Hi @seidnerj
Of course! happy to help!
Here is the endpoint available for non master account users:

I’ll share your feedback with the Docs team, so we can improve the changelog and include the appropriate documentation link.

At this time, we do not support sending SMS on behalf of other users (whether using a Server to Server oauth app or General Oauth admin manage app)

I am working closely with the PM for this endpoint to explore enhancements to its functionality.

Regarding your current workaround, it might be the only way to do it, but instead of asking your uses to re-authorize the app every 90 days, you can refresh the access token using the refresh_token included in the OAuth response payload.

Let me know if this helps!

Hi, yes - that is what I am doing, using the refresh token, but once every 90 days I need to have them re-authenticate, which is not good usability.

You should not need to have them re authenticate if you store the refresh token

I am already doing that, but I assumed that there is some kind of cap on the overall expiration of a refresh token “chain” at which point the end user needs to re-approve, is that not the case? if not, that is great.

No, as long as you refresh the access_token and store the new refresh token that gets back in the response, you won’t need to re authorize the app. Just make sure to store the new refresh token

Awesome! I am already doing that. Thx.

1 Like