Service limits for Azure Communication Services
This document explains the limitations of Azure Communication Services APIs and possible resolutions.
Throttling patterns and architecture
When you hit service limitations, you will receive an HTTP status code 429 (Too many requests). In general, the following are best practices for handling throttling:
- Reduce the number of operations per request.
- Reduce the frequency of calls.
- Avoid immediate retries because all requests accrue against your usage limits.
You can find more general guidance on how to set up your service architecture to handle throttling and limitations in the Azure Architecture documentation for throttling patterns. Throttling limits can be increased through a request to Azure Support.
- Go to Azure portal
- Select Help+Support
- Click on Create new support request
- In the Problem description, please choose Issue type as Technical and add in the details.
You can follow the documentation for creating request to Azure Support.
Acquiring phone numbers
Before acquiring a phone number, make sure your subscription meets the geographic and subscription requirements. Otherwise, you can't purchase a phone number. The below limitations apply to purchasing numbers through the Phone Numbers SDK and the Azure portal.
Operation | Scope | Timeframe | Limit (number of requests) |
---|---|---|---|
Purchase phone number | Azure tenant | - | 1 |
Search for phone numbers | Azure tenant | one week | 5 |
Action to take
For more information, see the phone number types concept page and the telephony concept overview page.
If you want to purchase more phone numbers or place a special order, follow the instructions here. If you would like to port toll-free phone numbers from external accounts to their Azure Communication Services account, follow the instructions here.
Identity
Operation | Timeframes (seconds) | Limit (number of requests) |
---|---|---|
Create identity | 30 | 1000 |
Delete identity | 30 | 500 |
Issue access token | 30 | 1000 |
Revoke access token | 30 | 500 |
createUserAndToken | 30 | 1000 |
exchangeTokens | 30 | 500 |
Action to take
We recommend acquiring identities and tokens before creating chat threads or starting calls. For example, when the webpage loads or the application starts.
For more information, see the identity concept overview page.
SMS
When sending or receiving a high volume of messages, you might receive a 429
error. This error indicates you're hitting the service limitations, and your messages will be queued to be sent once the number of requests is below the threshold.
Rate Limits for SMS:
Operation | Number Type | Scope | Timeframe (s) | Limit (request #) | Message units per minute |
---|---|---|---|---|---|
Send Message | Toll-Free | Per Number | 60 | 200 | 200 |
Send Message | Short Code | Per Number | 60 | 6000 | 6000 |
Send Message | Alphanumeric Sender ID | Per resource | 60 | 600 | 600 |
Action to take
If you have requirements that exceed the rate-limits, submit a request to Azure Support to enable higher throughput.
For more information on the SMS SDK and service, see the SMS SDK overview page or the SMS FAQ page.
There is a limit on the number of email messages you can send. If you exceed the below limits on your subscription, your requests will be rejected. You can attempt these requests again, after the Retry-After time has passed. Please take necessary action and request to raise the sending volume limits if needed.
Rate Limits
Operation | Scope | Timeframe (minutes) | Limit (number of emails) |
---|---|---|---|
Send Email | Per Subscription | 1 | 30 |
Send Email | Per Subscription | 60 | 100 |
Get Email Status | Per Subscription | 1 | 60 |
Get Email Status | Per Subscription | 60 | 200 |
Operation | Scope | Timeframe (minutes) | Limit (number of emails) |
---|---|---|---|
Send Email | Per Subscription | 1 | 5 |
Send Email | Per Subscription | 60 | 10 |
Get Email Status | Per Subscription | 1 | 10 |
Get Email Status | Per Subscription | 60 | 20 |
Size Limits
Name | Limit |
---|---|
Number of recipients in Email | 50 |
Total email request size (including attachments) | 10 MB |
Action to take
This sandbox setup is to help developers start building the application. Once you have established a sender reputation by sending mails, you can request to increase the sending volume limits. Submit a support request to raise your desired email sending limit if you require sending a volume of messages exceeding the rate limits. Email quota increase requests are not automatically approved. The reviewing team will consider your overall sender reputation, which includes factors such as your email delivery failure rates, your domain reputation, and reports of spam and abuse when determining approval status.
Note
Email quota increase requests may take up to 72 hours to be evaluated and approved, especially for requests that come in on Friday afternoon.
Chat
Size Limits
Name | Limit |
---|---|
Number of participants in thread | 250 |
Batch of participants - CreateThread | 200 |
Batch of participants - AddParticipant | 200 |
Page size - ListMessages | 200 |
Message Size | 28 KB |
Number of Azure Communication Services resources per Azure Bot | 1000 |
Rate Limits
Operation | Scope | Limit per 10 seconds | Limit per minute |
---|---|---|---|
Create chat thread | per User | 10 | - |
Delete chat thread | per User | 10 | - |
Update chat thread | per Chat thread | 5 | - |
Add participants / remove participants | per Chat thread | 10 | 30 |
Get chat thread / List chat threads | per User | 50 | - |
Get chat message | per User per chat thread | 50 | - |
Get chat message | per Chat thread | 250 | - |
List chat messages | per User per chat thread | 50 | 200 |
List chat messages | per Chat thread | 250 | 400 |
Get read receipts (20 participant limit**) | per User per chat thread | 5 | - |
Get read receipts (20 participant limit**) | per Chat thread | 100 | - |
List chat thread participants | per User per chat thread | 10 | - |
List chat thread participants | per Chat thread | 250 | - |
Send message / update message / delete message | per Chat thread | 10 | 30 |
Send read receipt | per User per chat thread | 10 | 30 |
Send typing indicator | per User per chat thread | 5 | 15 |
Send typing indicator | per Chat thread | 10 | 30 |
Note
** Read receipts and typing indicators are not supported on chat threads with more than 20 participants.
Chat storage
Azure Communication Services stores chat messages indefinitely till they are deleted by the customer.
Beginning in CY24 Q1, customers must choose between indefinite message retention or automatic deletion after 90 days. Existing messages remain unaffected, but customers can opt for a 90-day retention period if desired.
Note
Accidentally deleted messages are not recoverable by the system.
Voice and video calling
PSTN Call limitations
Name | Scope | Limit |
---|---|---|
Default number of outbound concurrent calls | per Number | 2 |
Call maximum limitations
Name | Limit |
---|---|
Number of participants | 350 |
Calling SDK streaming support
The Communication Services Calling SDK supports the following streaming configurations:
Limit | Web | Windows/Android/iOS |
---|---|---|
Maximum # of outgoing local streams that you can send simultaneously | one video or one screen sharing | one video + one screen sharing |
Maximum # of incoming remote streams that you can render simultaneously | 9 videos + one screen sharing | 9 videos + one screen sharing |
While the Calling SDK will not enforce these limits, your users may experience performance degradation if they're exceeded.
Calling SDK timeouts
The following timeouts apply to the Communication Services Calling SDKs:
Action | Timeout in seconds |
---|---|
Reconnect/removal participant | 120 |
Add or remove new modality from a call (Start/stop video or screen sharing) | 40 |
Call Transfer operation timeout | 60 |
1:1 call establishment timeout | 85 |
Group call establishment timeout | 85 |
PSTN call establishment timeout | 115 |
Promote 1:1 call to a group call timeout | 115 |
Action to take
For more information about the voice and video calling SDK and service, see the calling SDK overview page or known issues.
Job Router
When sending or receiving a high volume of requests, you might receive a ThrottleLimitExceededException
error. This error indicates you're hitting the service limitations, and your requests will be dropped until the token of bucket to handle requests is replenished after a certain time.
Rate Limits for Job Router:
Operation | Scope | Timeframe (seconds) | Limit (number of requests) | Timeout in seconds |
---|---|---|---|---|
General Requests | Per Resource | 10 | 1000 | 10 |
Action to take
If you need to send a volume of messages that exceeds the rate limits, email us at acs-ccap@microsoft.com.
Teams Interoperability and Microsoft Graph
Using a Teams interoperability scenario, you'll likely use some Microsoft Graph APIs to create meetings.
Each service offered through Microsoft Graph has different limitations; service-specific limits are described here in more detail.
Action to take
When you implement error handling, use the HTTP error code 429 to detect throttling. The failed response includes the Retry-After
response header. Backing off requests using the Retry-After
delay is the fastest way to recover from throttling because Microsoft Graph continues to log resource usage while a client is being throttled.
You can find more information on Microsoft Graph throttling limits in the Microsoft Graph documentation.
Next steps
See the help and support options.
Feedback
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Submit and view feedback for