How to limit the amount of messages I can send using Twilio - twilio

I'm setting up a chatbot for Whatsapp using Twilio. My question is how can I set a limit on number of messages I can send in a day? It's for my protection, so that if some bug would send over a million messages then Twilio would make me bankrupt.

Heyoooo. 👋 Twilio Developer Evangelist here.
To my knowledge, it's not possible to limit the sent messages on the Twilio side. To set a hard limit you'd have to count and keep track of the sent messages on your end.
There are a few things that you can do that may help already.
Disable auto-recharge
If you're worried about going bankrupt disable auto-recharge for your project. This way you can't just send millions of messages in case your application goes wild.
Set up usage warnings
Additionally, you can set up usage triggers that will send a webhook to a URL you define if your app hits a certain threshold value. This URL could act like kill-switch to really shut everything down after x sent messages.
FYI, Twilio protects you of loops already
To protect your project, messages cannot be sent more than 15 times in a 30 second window between your Twilio phone number and another number. Doing so may trigger a 14107 warning that your message rate has been exceeded.
In case something goes wild Twilio will stop you from sending messages.
I hope that helps. Let me know it goes. :)

Related

Issue with character limit in Twilio and responding back manually

I'm facing some challenges with Twilio and was wondering if someone knows how to resolve them. First, would like to highlight that I don't have a programming background but I can write low-level code.
Current Case:
A session is booked > Record is created in Airtable via a Zap with calendly > Twilio sends a message using the info in Airtable via a zap with calendly.
Problems:
I'm currently only able to send 160 characters in the message. If the message is longer, only the first 160 characters are sent and the message is cut short (e.g. looking forwa....)
I don't have an easy way to respond back to messages. Currently Twilio forward all messages to a Voice number in one big thread and I have to respond back in this format
+1123456789: Message.
This is confusing and causes a lot of issues.
Is there any way to build something in Twilio which allows for manual responding?
Thank you all in advance!
Twilio developer evangelist here.
I'm currently only able to send 160 characters in the message. If the message is longer, only the first 160 characters are sent and the message is cut short (e.g. looking forwa....)
This sounds like a limitation of the Zap you are using. SMS messages are 160 characters in length, but Twilio can stitch together up to 10 messages, allowing you to send up to 1600 characters. Twilio doesn't truncate the messages either, so it sounds like something the Zap is doing. In 2017 Zapier did announce that you could send longer messages with their integration, you just had to update your Zap with the right setting.
I don't have an easy way to respond back to messages. Currently Twilio forward all messages to a Voice number in one big thread and I have to respond back in this format +1123456789: Message. This is confusing and causes a lot of issues. Is there any way to build something in Twilio which allows for manual responding?
You could certainly build something. Or integrate with an app like Front which can give you a shared inbox for things like incoming SMS from Twilio.

Twilio Response from a non-twilio number

When my friends text my Twilio bot, Twilio responds from another number which is not even Twilio's and is named "SMSInfo". I expect the bot to respond from the same number. I assure you that I haven't set any logic there that a response should come from another number. Also, note that "SMSInfo" is a number which often sends them verification codes for Fiverr or other things.
I just submitted a ticket to Twilio support and a bot automatically suggested me few articles. One of them solved the issue.
Sender ID change may occur when you send messages from a Twilio number
that is not local to your recipients, for example using a US Twilio
number to send SMS to Polish mobile users. This is often done to
comply with local regulations, or to ensure the highest possible
delivery rate for your messages.

Voice/SMS testing API or call lists

I am building an app using Twilio to send out text messages and phone calls. It works great but I know there are limits to the amount of messages to send out per number in any given day. The app is going to be used to send out messages in the thousands at times, for instance to alert contacts about weather cancellations.
Since I am still developing, I do not want to send out real messages to thousands of real numbers a bunch of times while I test and configure my code.
Is there any phone apis, lists, etc. of dummy numbers that can be used as my example contacts that will at least return some form of TRUE that the number exists and received my call/message? Or return something else if I hit a use limit because of the number of messages I am sending.
I think I could get everything setup with a list of 1000 numbers since I can plan out every 250-500 calls, do this or that.
Twilio developer evangelist here.
There are no lists like that that I know of.
You do have a set of test credentials that you can use to send messages to a few "magic" numbers that will behave as if the message was successful (or failed for some reason). However there's only one success message here.
The thing about the limits of 200-250 messages per number per day is that they aren't hard limits. They are just around the level that carriers will start to consider blocking your messages. At that point you will likely still get a positive response from the Twilio API as a message is queued to be sent, but it may or may not fail at delivery time.
I recommend you look into Twilio's messaging services, they allow you to create a number pool that messages are sent from. If you are sending a number of the same messages at the same time, you can also check out Twilio Notify for sending notifications. I recently wrote up a blog post on how to set up a messaging service, number pool and Notify for bulk SMS.
Let me know if that helps at all.

Twilio: does the area code affect SMS delivery speed?

We are a mobile app that uses Twilio for phone number verification.
And experiencing a small percentage of our user base getting their SMS very slow (over 2 mins).
Right now we have ~100 Twilio phone numbers which we use in a round robin chain format (so we don't hit any API limits).
Does the area code of the Twilio phone number that sends the SMS affect delivery speed? If so, we can buy a phone number in each area code and sent user's their verification SMS from a Twilio number in the exact same area code.
Here is an example of a delivery that took several minutes:
Twilio developer evangelist here.
The area code of a Twilio number should not affect the delivery speed at all. If you are concerned about this then I recommend you get in touch with Twilio support and send them some of the message SIDs you're worried about. They can track down why there might be delays with the carriers.
Just as a note, you don't need to do the round robin yourself. Take a look at Twilio's Copilot. It allows for geomatching (on an international basis) and also gives you sticky sender so that users will always receive messages from the same number.

Can I configure a twilio long number to opt a number back in

If a customer sends STOP to my app's twilio number, twilio will block me sending to that number until the customer texts START. Is there any way around this so that if the customer gave me consent verbally, for example, I can turn the number back on? Or can I configure a long code so that I handle the consent in my app?
Twilio developer evangelist here.
There is no way around this other than having the customer send an SMS saying START, YES or UNSTOP to your number.
Note, when a user opts out of getting messages from one of your Twilio numbers, so you could contact them on a different Twilio number if you had different reason to believe that the user wanted to opt in again without sending one of the above messages.
Let me know if that helps at all.

Resources