Skip to main content

Rate Limits

This guide will walk through the recommended approach to managing queues and rate limits for use with the Messaging API. Over the past years mobile telecom operators have begun to block what is deemed automated traffic (A2P) sent over standard local telephone numbers IE: (919)-430-5555. The amount of messages sent in this way have increased due to spreading automated traffic (A2P) across multiple local telephone numbers to bypass volumetric filters. This process is called "snowshoeing" and as a result, the mobile operators are not only blocking volumetrically, but are also finger-printing content and preemptively blocking messages even from a "fresh" phone number.

How Bandwidth Helps#

In response to the ever changing (& unregulated) landscape of telecommunications and text messaging, Bandwidth has implemented a new rate-limit process and look-ahead Spam filtering service to help our customers ensure deliver-ability of their messages.

More information about the types of messaging Bandwidth supports can be found in the "What is P2P and A2P Messaging?" article.

Spam filtering and A2P Best Practice#

Bandwidth uses the same network protection technology as the mobile telco operators. This allows us to screen messages before they're sent to the downstream carrier. By checking before Bandwidth passes the message along, we're able to work with you to understand and fix any potential issues with the message. This maintains your telephone number deliverability reputation and helps build predictable traffic patterns. If the message is marked as Spam we will send a notification to the application specified in the create message request.

At Bandwidth, we want to help our customers follow best practices for toll-free (A2P) messaging. All messaging traffic is required to comply with relevant laws and regulations, including (but not limited to) the Telephone Consumer Protection Act (TCPA). Please note, this article does not constitute legal advice.

Default Messaging Rate Limits and Queues#

All Bandwidth messaging products are rate limited in some fashion and messages will be queued internally to send out.

Rate limits on messages are applied to segment count, not API request. This means that a 2 segment message would count as 2 messages against your rate limit.

For more information about rate limits and queues, please visit the links below:

429 – Too Many Requests#

It is important to note, when you max out your account level rate limit and your queue size has been exceeded, you will receive a 429 - Too Many Requests error.

Sample Message Rate Limit Response#

You will receive this error response if:

  • Your per account queue is full
Status: 429 Too Many Requests
Content-Type: application/json; charset=utf-8
{
"type": "max-message-queue-size-exceeded",
"description": "The SMS queue for your account is full and cannot accept more messages right now. Your allowed rate is 60 messages per minute. The capacity of this queue is 900 messages (15 minutes). Reduce your message sending rate, or contact support to increase your allowed rate."
}

Managing Messages#

MethodDescriptionUse-cases
Back-off and RetryTry to send messages as quickly as possible to Bandwidth. When you hit the rate limit, add a small delay and try again. If it fails, then add some more delay and try againWorks best for use-cases that need to send lots of messages with no priority:
- Day before appointment reminders
- Receipts
- Opted-in Promotions
ThrottleOnly send messages to Bandwidth as quickly as your dequeue ratesWorks best with any use case, but favors pure P2P
Queue ManagementUtilizing a queue system such as RabbitMQ or MosquittoWorks best for use-cases that intermingle massive campaigns with realtime traffic. Enables full control over message priority and time-to-live

Back-off and Retry#

Back-off and Retry adaptively increases delay to attempt to find the quickest possible call pacing without hitting rate limits. The pseudocode below shows a simple example using a linear coefficient to adjust delay. Introducing randomness or "jitter" into the delay can help reduce successive collisions.

retries = 0
coefficient = 2 // coefficient to increase delay
delay = some milliseconds (small amount)
DO
status = Get the result of the asynchronous operation.
IF status = SUCCESS
retry = false
ELSE IF status = TIMEOUT
retry = true
retries = retries + 1
WAIT delay
delay = coefficient * delay
END IF
WHILE (retry AND (retries < MAX_RETRIES))

Throttling#

Throttling paces the asynchronous operations based on a specified time duration. Using a duration just longer than the rate limit will help ensure calls are completed as they are sent without having to resend due to rate limiting.

retries = 0
DO
status = Get the result of the asynchronous operation.
IF status = SUCCESS
retry = false
ELSE IF status = TIMEOUT
retry = true
retries = retries + 1
WAIT some milliseconds
END IF
WHILE (retry AND (retries < MAX_RETRIES))

Queue Management#

Queue Management requires configuring and maintaining a queue of asynchronous operations, http API calls for example, facilitating linear control over when the operation is executed. The pseudocode below shows a simple queuing solution. For complex queuing tasks, consider using a queue system such as RabbitMQ or Mosquitto.

1. CONFIGURE_QUEUE size, storage, etc
2. PUSH_TO_QUEUE add async operation data to queue
3. SUBSCRIBE_TO_QUEUE get async operation from queue
BEGIN_HANDLER
DO
message = extracted from queue of async operations
status = execute async operation with message
IF status = SUCCESS
retry = false
ELSE IF status = TIMEOUT
retry = true
retries = retries + 1
WAIT delay
END IF
WHILE (retry AND (retries < MAX_RETRIES))
END_HANDLER