Does a Twilio Messaging Service prevent "snowshoe messaging" when sending a bulk text? - twilio

I've been reading up on the Twilio documentation regarding text queue limits for long code numbers (14,400 segments max for 1 MPS). The docs suggest adding more numbers to a Messaging Service to load balance many requests. However, I also read in the docs that texts can be filtered by carriers if their systems detect "snowshoe" messaging - meaning that the same text is being sent from multiple numbers.
So if I have 2 US local numbers in my Messaging Service, will Twilio help prevent snowshoe-ing somehow since it suggests adding more numbers to load balance? I can't seem to find a definitive answer.
Thanks for any help!

Twilio developer evangelist here.
While adding numbers to a messaging service can increase your throughput it is not recommended when sending the same message out to numbers in the US and Canada. If you are looking for higher throughput it is better to consider toll-free numbers or short codes. You can read more about choosing toll-free or short code numbers here. For even more certainty sending mass messages, you should investigate whether registering for A2P 10DLC could work for you and bring you higher throughput and better deliverability instead.

Related

How do sites like Vonage or PhoneValidator determine whether a phone number is mobile or a landline?

Sorry if this isn't the proper channel for this question; it's hard to tell where else to put it.
Primary Question
Given a phone number (in my case: US or +1), I want to know whether that phone number is designated for use with mobile or landline phones (exclusive or). (Optionally: can I determine whether they were ported?)
I know that the ability to port numbers implies that no data on this is 100% accurate. I'm only looking to be about as accurate as existing services like Vonage's Number Insight API, or PhoneValidator.com, without giving them my customer's phone numbers directly. I'd preferably like to know how they acquire their information so I can replicate it.
I do know that NANPA publishes Central Office Code Assignment Records, which is enough to get me the company who 'owns' a block of numbers, but that doesn't necessarily tell me whether they're mobile or landline blocks.
Reading the TYPE from Google's libphonenumber gives the rather unhelpful FIXED_LINE_OR_MOBILE response, whereas I'm looking for which device type specifically.
Secondary question:
Given that NANPA hands out phone numbers in blocks of 1000, am I safe to presume that a random number within that block is representative of the whole block? In other words: does 222-222-2000 being a mobile number imply that 2000 through 2999 is?
Thank you!

Twilio calls keep failing-- I think i've been filtered/blacklisted by carrier. What is limit or best practice around this

TL;DR Twilio calls keep failing-- I think i've been filtered/blacklisted by carrier. What is limit I'm hitting up against and/or best practice around this.
Further description
I'm trying to automate leaving voicemail in an outbound sales effort.
After a handful of calls, any further calls for a given number return 'Failed', with description 'Invalid Phone Number' 13224.
I'm assuming I'm being throttled by the carriers for suspicious/annoying robo-dialing.
Are there rules of thumb for avoiding this blacklisting?
Twilio developer evangelist here.
Error 13224 does suggest you have invalid numbers rather than are being blocked. The full message is:
Dial: Twilio does not support calling this number or the number is invalid
This error occurs when the provided number is not in E.164 format; for example using local dialing pattern 01234567890 instead of the full E.164 address +441234567890. This can also occur when calls are attempted to non-existent country codes, area codes, or exchanges. For example, there is no +693 country code, no +1238 US area code, and no 555 US exchange.
This can also occur with properly-formatted, valid destinations if none of Twilio’s carrier partners are able to deliver the call; for example a telecom network outage in the phone number’s local area.
Have you ensured the numbers you are dialling are in fact in full E.164 format?

Specifying multiple Twilio numbers when sending an SMS to spread load over all numbers

I am new to Twilio and was reading that the limit is 1 SMS per Second per Number.
If you have more phone numbers, then the overall sending rate increases.
My question is if we need to specify multiple numbers in the code in order to take advantage of the increased rate with having more numbers, or is this taken care of automatically by Twilio, even when I specify only one number in the code?
It is not clear if I manually have to Round Robin across all my numbers myself, or if Twilio does this for us.
I am using PHP to do this.
Twilio evangelist here.
You will have to write the code that round robins across all of the numbers in your account. This should be pretty straight-forward.
What I would do is put all of those numbers in an array (you can use the REST API to get the list of all of your Twilio phone numbers), and then in your message sending loop, just use a counter to keep track of your place in that array. Once that counter reaches the array size, just reset it to 0 to start over at the beginning of the array.
Hope that helps.
Over the years the answer to this question has changed. There is now a Twilio service called Copilot which enables all kinds of number intelligence. See the docs here for examples of how to use it. That docs page lists it as a "public beta" (though it also suggests sending API queries to the 2010 version of their API, so it seems a bit outdated).
Edit: Be sure to read the docs regarding the response, since the Copilot behavior is different than the standard message sending behavior:
There is a slight difference in API response when specifying the MessagingServiceSid parameter. When you only specify the From parameter, Twilio will validate the phone numbers synchronously and return either a queued status or an error. When specifying the MessagingServiceSid parameter, Twilio will first return an accepted status.

Pattern for recording the price of Twilio phone calls

Would like to maintain a local record of the price of all the phone calls that my application makes.
Am not sure what a good pattern for this would be. It looks like the price is not available in the arguments provided during the status call back when the call is closed. I assume this means I'll need to query Twilio's servers to find the price of the call. Can I do this immediately or do I need to wait a certain amount of time for the price to populate?
Is there another pattern that would be simpler, require fewer steps, or be less error prone that I am not seeing here?
Thanks!
Twilio evangelist here.
I'd recommend checking out the Usage Records API. These handy API's give you an easy way to get rollup data for your account, like how much your account spent yesterday, or how many outbound calls it made.
You can also set up Usage Triggers to proactively notify you when threshholds are met.
Hope that helps.

How to call 200 UK cell phones simultaneously and deliver a recorded message?

Working on a fun element for a big company event.
I would like to find a way to call 200 UK cell/mobile numbers as simultaneously as possible and deliver the same recorded message to each of them. All of the target devices belong to people attending the event.
Anybody managed to do something similar?
I think I could do this with Twilio's APIs, but a more packaged solution is preferred.
Any risk of overwhelming the local cells by trying to start a call with so many devices in the same area at once?
Twilio Evangelist here.
This is totally possible with Twilio and some simple programming logic. With the numbers you have, you can loop through them and create phone calls like so (in Python):
for num in number:
# Create a phone call
client.calls.create(
to=num,
from_='MY_TWILIO_NUMBER',
url='http://mywebsite.com/instructions.xml'
)
The url here (final line) will provide some basic TwiML to play an MP3 file.
There are solutions for this available, but it is likely you'll be able to build this in software faster than you will be able to get the solution running, especially if this is for a one-time event and you have some software people handy.
If you need any help, let me know!

Resources