Skip to main content

HI. We are presently writing an integration for our product to use RingCentral as a way to send SMS for our customers. Our web based application is primarily send SMS for Appointment Reminders. As part of the flow for integrations, our customers will be redirected to the RingCentral oAuth.. and once that is complete, then they will choose which phone number to use. I have 2 Questions:


1) Why is there an inconsistance in the phone number "features". When I call `/restapi/v1.0/account/accountId/extension/extensionId/phone-number ` I get a list of phone numbers for that account/extension.. of which each one has a `features` array, which I check that it has `SmsSender` in it so it is good to use for SMS. This property ('features') only shows up on that endpoint. If I call the GetPhoneNumber single end point (`/restapi/v1.0/account/accountId/phone-number/phoneNumberId `) or the `ListCompanyPhoneNumbers' (/restapi/v1.0/account/accountId/phone-number ) endpoint it doesn't have a `features ` property. Seems to me to be an inconsistant data model, why is it features is only returned under the extension endpoint.


2) In addition to checking that the phone number has a `features ` of "SmsSender" , is there any thing else that may effect its usability for sending SMS. I'm specifically asking about properties like `paymentType `, `status `, `type `, `subType ` and `usageType` . It looks like a 'Status' of 'Normal' is required. In the C# quickstart it seems to only check `feature == "SmsSender" `

1) When you call the endpoint /extensionId/phone-number, you read all the phone numbers which that extension (identified by the id) can use with the feature(s) associated with that number. The CallerId feature is for using that number as a caller id, SmsSender feature is for using the number to send SMS message etc. If you parse the usageType, you will see the type of that number as a DirectNumber, or a MainCompanyNumber or a CompanyNumber etc.

When a number is a direct number, the number would have the CallerId and SmsSender or A2PSmsSender etc. so that the user is the owner of the number and he/she can call and send SMS from that number.

When a number has only the CallerId feature, the number is either a company number, or a main company number. It is a shared number that all extensions can be used as a caller id when making a voice call. But if it is a direct number with only the CallerId feature, this means that the number is not SMS enabled (not provisioned for SMS)

When a number is a main company number, or a company number with the callerId and e.g. SmsSender features. It means that this extension is set via the IVR settings as the extension that handles call and SMS for that company or main company number. If you open the IVR setting and reassign the number to another extension, the SmsSender feature will be reassigned to the new extension.

The other 2 endpoints are just for reading all numbers belong to the account.

2) It's sufficient to rely on the SmsSender or A2PSmsSender feature to decide that if you can send text messages from that number using the access token of that user extension or not. Similar, if it has the MmsSender feature, then you can send MMS message, if it has the InternationalSmsSender feature, then you can send international SMS messages.


1) So `features` are an attribute of the Extension/Phonenumber relationship.. not an attribute of the PhoneNumber itself?


2) Can one/all or any combination of SmsSender/A2PSmsSender and InternationalSmsSender be a feature of a phone number (i.e. can be both SmsSender and A2PSmsSender)


Reply