Programmable Chat has been deprecated and is no longer supported. Instead, we'll be focusing on the next generation of chat: Twilio Conversations. Find out more about the EOL process here.
If you're starting a new project, please visit the Conversations Docs to begin. If you've already built on Programmable Chat, please visit our Migration Guide to learn about how to switch.
Twilio Programmable Chat has a number of limits in place which will constrain certain elements of the system and how it is used. Some limits have default values and can be configured, others are not able to be changed.
The Chat limits are enforced at Service instance, User and Channel levels. These limits are set within a Service instance scope.
Counter limits are related on object list counts/maximum enforced length. If an enforced count limit will be exceeded by means of a command, this command will be rejected with a 403
status code along with a more specific chat error code and description.
Default: 250 Maximum: 1,000
Configured via: Service Instance configuration: Limits.UserChannels
Default: 100 Maximum: 1,000
Configured via: Service Instance configuration: Limits.ChannelMembers
Unlimited. Each Chat Service Instance can hold as many channels as you wish!
Limits of this type will impact the number of simultaneous actions that can be performed within a Service Instance.
Actions per Second (APS) is a maximum request rate that governs your chat applications. This limit is specifically enforced for mutation commands such as sending a Message or creating a Channel, both via the REST API and from the front-end Chat SDKs (iOS, Android, Browser). Read actions are not limited under APS.
The following operations are rate-limited per channel, with a default maximum set at 30 APS separately for each channel:
The following operations are governed globally, with a single 30 APS limit applying to each Chat Service as a whole:
The Chat backend measures the average request rate over a 5s sliding window. This means in a particular second, you could actually execute 150 APS even though your limit is 30.
Requests that go over APS threshold are rejected with HTTP status code 429
Too Many Requests. After this your application client request logic needs to wait until the average goes below threshold to make any command requests again. We recommend exponential backoff of such requests, ideally with jitter to decrease overall latency. We recommend that every Chat application should implement retry logic.
If your application's sustained request rate is getting close to the limit and throttling becomes commonplace, the APS cap may need to be increased for that service instance. Please contact support in this case.
Limits for user-provided data are herein specified in UTF-8 character counts. If a payload limit is specified in bytes, we assume that the data is serialized using UTF-8 encoding where each character (e.g. emoticon) may take more than one byte.
Resource | Field | Maximum length / Size |
---|---|---|
ServiceInstance | FriendlyName | 256 characters |
Channel | FriendlyName | 256 characters |
Channel | UniqueName | 256 characters |
Channel | Attributes | 32 KiB |
Channel | CreatedBy | 256 characters |
User | Identity | 256 characters |
User | Attributes | 32 KiB |
User | FriendlyName | 256 characters |
Message | Body | 32 KiB |
Message | Attributes | 4 KiB |
Message | CreatedBy | 256 characters |
Message | LastUpdatedBy | 256 characters |
Role | FriendlyName | 256 characters |
Credential | FriendlyName | 64 characters |
Maximum Media file size: 150 MiB
Twilio Programmable Chat also apply rate limits to the actions (reads/writes/updates) in order to ensure quality of service for all our customers.
The following tables summarize the various connection limits that are applied for SDKs:
Limited Quantity | Prescribed Limit | Notes |
---|---|---|
Number of Concurrent Connections | up to 7,000 in each Twilio Subaccount and 100,000 overall, shared among all your Subaccounts. | The number of concurrent connections through Twilio's internal websockets. |
Rate of Connection Establishment | up to 110/s in each Twilio Subaccount and 1,000/s overall, shared among all your Subaccounts. | The number of new or re-established connections per second through Twilio's internal websockets. |
Rate of Upstream Requests | up to 2,000/s per connection and up to 20,000/s per Subaccounts | The number of upstream requests per second that pass through Twilio's internal websockets. |