This article explains the limitations of Azure Communication Services APIs and possible resolutions.
Throttling patterns and architecture
When you reach service limitations, you receive an HTTP status code 429 (too many requests). In general, the following best practices are used for throttling:
Reduce the number of operations per request.
Reduce the frequency of calls.
Avoid immediate retries because all requests accrue against your usage limits.
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. To increase throttling limits, make a request to Azure Support.
Before you acquire a phone number, make sure your subscription meets the geographic and subscription requirements. Otherwise, you can't purchase a phone number. The following limitations apply to purchasing numbers through the Phone numbers SDK and the Azure portal.
In the Describe your issue text box, enter Technical, and then select Go.
From the Select a service dropdown menu, select Service and Subscription Limits (Quotas), and then select Next.
At the Problem description, choose the Issue type, Subscription, and Quota type values, and then select Next.
Review any recommended solutions, if available, and then select Next.
Add more details as needed, and then select Next.
At Review + create check the information, make changes as needed, and then select Create.
Identity
Operation
Time frames (seconds)
Limit (number of requests)
Create identity
30
1,000
Delete identity
30
500
Issue access token
30
1,000
Revoke access token
30
500
createUserAndToken
30
1,000
exchangeTokens
30
500
Action to take
We recommend that you acquire identities and tokens before you create chat threads or start calls. For example, do this task when the webpage loads or the application starts.
When you send or receive a high volume of messages, you might receive a 429 error. This error indicates that you're about to reach the service limitations. Your messages are queued and are sent after the number of requests is below the threshold.
Rate limits for SMS:
Operation
Number type
Scope
Time frames
Limit (request number)
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.
You can send a limited number of email messages. If you exceed the email rate limits for your subscription, your requests are rejected. You can attempt these requests again, after the Retry-After time passes. Take action before reaching the limit by requesting to raise your sending volume limits if needed.
The Azure Communication Services email service is designed to support high throughput. However, the service imposes initial rate limits to help customers onboard smoothly and avoid some of the issues that can occur when switching to a new email service.
We recommend gradually increasing your email volume using Azure Communication Services Email over a period of two to four weeks, while closely monitoring the delivery status of your emails. This gradual increase enables third-party email service providers to adapt to the change in IP for your domain's email traffic. The gradual change gives you time to protect your sender reputation and maintain the reliability of your email delivery.
Azure Communication Services email service supports high volume up to 1-2 million messages per hour. High throughput can be enabled based on several factors, including:
Customer peak traffic
Business needs
Ability to manage failure rates
Domain reputation
Failure Rate Requirements
To enable a high email quota, your email failure rate must be less than one percent (1%). If your failure rate is high, you must resolve the issues before requesting a quota increase.
Customers are expected to actively monitor their failure rates.
If the failure rate increases after a quota increase, Azure Communication Services will contact the customer for immediate action and a resolution timeline. In extreme cases, if the failure rate isn't managed within the specified timeline, Azure Communication Services may reduce or suspend service until the issue is resolved.
Related articles
Azure Communication Services provides rich logs and analytics to help monitor and manage failure rates. For more information, see the following articles:
To request higher limits, follow the instructions at Quota increase for email domains. Higher quotas are only available for verified custom domains, not Azure-managed domains.
Maximum authenticated connections per subscription
250
For all message size limits, consider that Base64 encoding increases the size of the message. You need to increase the size value to account for the message size increase that occurs after the message attachments and any other binary data are Base64 encoded. Base64 encoding increases the size of the message by about 33%, so the message size is about 33% larger than the message sizes before encoding. For example, if you specify a maximum message size value of approximately 10 MB, you can expect a realistic maximum message size value of approximately 7.5 MB.
Send attachments larger than 10 MB
To email file attachments up to 30 MB, make a support request.
If you need to send email file attachments larger than 30 MB, use this alternative solution. Store the files in an Azure Blob Storage account and include a link to the files in your email. You can secure the files with a shared access signature (SAS). A SAS provides secure delegated access to resources in your storage account. By using a SAS, you have granular control over how clients can access your data.
Benefits of using a Blob Storage account:
You can handle large-scale files.
You can use a SAS or keys to precisely manage file access.
Email quota increase requests might take up to 72 hours for evaluation and approval, especially for requests that come in on Friday afternoon.
Chat
Azure Communication Services supports chat.
Size limits for chat
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 Service
1,000
Rate limits for chat
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 or remove participants
Per chat thread
10
30
Get chat thread or 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, or 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 aren't supported on chat threads with more than 20 participants.
Chat storage
Azure Communication Services stores chat messages according to the retention policy that you set when you create a chat thread.
Important
Functionality described in this article is currently in public preview.
This preview version is provided without a service-level agreement, and we don't recommend it for production workloads. Certain features might not be supported or might have constrained capabilities.
For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
You can choose between indefinite message retention or automatic deletion between 30 and 90 days via the retention policy on the Create Chat Thread API. Alternatively, you can choose not to set a retention policy on a chat thread.
If you have strict compliance needs, we recommend that you use the Delete Chat Thread API to delete chat threads. Any threads created before the new retention policy aren't affected unless you specifically change the policy for that thread.
Note
If you accidentally delete messages, the system can't recover them. If you submit a support request for a deleted chat thread after the retention policy deletes that thread, it can't be retrieved. Information about that thread is no longer available. If needed, open a support ticket as quickly as possible within the 30-day window after you created a thread so that we can assist you.
Voice and video calling
Azure Communication Services supports voice and video calling.
PSTN call limitations
Name
Scope
Limit
Default number of outbound concurrent calls
Per number
2
Note
There are no limits on inbound concurrent calls. You can also submit a request to Azure Support to increase the limit for outbound concurrent calls. Our vetting team reviews all requests.
Call maximum limitations
Name
Limit
Number of participants
350
Calling SDK streaming support
The Azure Communication Services Calling SDK supports the following streaming configurations:
Limit
Web
Windows/Android/iOS
Maximum number of outgoing local streams that you can send simultaneously.
One video or one screen sharing
One video + one screen sharing
Maximum number of incoming remote streams that you can render simultaneously.
Nine videos + one screen sharing
Nine videos + one screen sharing
The Calling SDK doesn't enforce these limits, but your users might experience performance degradation if you exceed these limits.
Calling SDK timeouts
The following timeouts apply to the Azure Communication Services Calling SDKs:
Action
Timeout in seconds
Reconnect or remove a participant.
120
Add or remove new modality from a call. (Start or stop video or screen sharing.)
When you send or receive a high volume of requests, you might receive a ThrottleLimitExceededException error. This error indicates that you're reaching the service limitations. Your requests fail until the token bucket that's used to handle requests is replenished after a certain time.
Rate limits for Job Router
Operation
Scope
Time frame (seconds)
Limit (number of requests)
Timeout in seconds
General requests
Per resource
10
1,000
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
By using a Teams interoperability scenario, you likely use some Microsoft Graph APIs to create meetings.
Each service offered through Microsoft Graph has different limitations. Service-specific limits are described on this webpage 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. Use the Retry-After delay to back off requests. It's the fastest way to recover from throttling because Microsoft Graph continues to log resource use while a client is throttled.
You can find more information about Microsoft Graph throttling limits in the Microsoft Graph documentation.