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.
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.
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.
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:
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.
You will receive this error response if:
- Your per account queue is full
|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
- 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 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.
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.
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.