Rate this page:

Thanks for rating this page!

We are always striving to improve our documentation quality, and your feedback is valuable to us. How could this documentation serve you better?

Chat Limits

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

Counter limits are related on object list counts/maximum enforced length. If an enforced count 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.

Channels per User

Default: 250 Maximum: 1,000

Configured via: Service Instance configuration: Limits.UserChannels

Members per Channel

Default: 100 Maximum: 1,000

Configured via: Service Instance configuration: Limits.ChannelMembers

Throughput Limits

Limits of this type will impact the number of simultaneous actions that can be performed within a Service Instance.

Actions Per Second

APS is the guaranteed Actions Per Second that a Service instance will support. All Service instances have a baseline of 30 APS. Programmable Chat will allow short bursts above the baseline APS - up to 5x the baseline. If the bursts become sustained throughput, the Service will start rejecting requests.

Please note that the APS limit is enforced for commands such as sending a Message or creating a Channel - not Read actions. The following operations are applicable, subject to APS rate control:

  • All REST API operations that modify Chat resources using methods POST, PUT, DELETE.
  • All iOS/Android/JS client SDK commands that result in Chat resource mutation (e.g. sending a message, joining a channel), excluding initial login, token refresh and typing indicator.

How This Works

The request limit is based on average request rate in 5s sliding window. For example, for 30 req/s limit we allow burst up to 150 req/s. After this your application client request logic needs to wait until average goes below threshold to make any command requests again.

Requests that go over APS threshold are rejected with HTTP status code 429 Too Many Requests.

When the Throughput is Exceeded

For reliable handling of short-term bursts of requests towards the Chat REST API, please make sure your backend application implements a retry logic. When your application receives HTTP status code 429 back from the Chat service, it should repeat the request several times, using a good exponential back-off algorithm like the one advocated by Amazon.

If your sustained request rate is getting close to the limit and throttling persists, the APS cap may need to be increased for that service instance. Please contact support in this case.

Data Length/Size Limits

Limits for user provided data in UTF-8 characters. 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 Property Limits

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

Media Messaging

Maximum Media file size: 150 MiB

Rate this page:

Need some help?

We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd browsing the Twilio tag on Stack Overflow.