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

Method	Description	Use-cases
Back-off and Retry	Try 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 again	Works best for use-cases that need to send lots of messages with no priority: - Day before appointment reminders - Receipts - Opted-in Promotions
Throttle	Only send messages to Bandwidth as quickly as your dequeue rates	Works best with any use case, but favors pure P2P
Queue Management	Utilizing a queue system such as RabbitMQ or Mosquitto	Works 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

How Bandwidth Helps​

Spam filtering and A2P Best Practice​

Default Messaging Rate Limits and Queues​

429 – Too Many Requests​

Sample Message Rate Limit Response​

Managing Messages​

Back-off and Retry​

Throttling​

Queue Management​