I am working on an SMS-based service that parses incoming texts and sends a response, building on top of Twilio. I am concerned about a possible ddos which would result in increased costs. Is there a way of preventing this or limiting the number of times a user can send SMS without you being charged? I am based in Australia, so some of the alternatives to Twilio are not available with local numbers.
You can monitor inbound activity and if you see a massive influx, you can remove the webhook, as detailed here, which will prevent anymore SMS inbound toward your account.
Is there a way to block incoming SMS on my Twilio phone number?
Related
I have had a couple of customers wondering if they can use their own phone numbers to send out SMS using Twilio.
I am wondering if this is possible?
What are the carrier charges in this case and do I need to verify this number before enabling this functionality for an individual user?
The number you want to send messages from (or to) needs to be controlled by Twilio. However, it is possible to port your number from your current provider over to Twilio and thus give Twilio control over that number. This is possible, at least in some countries.
This support article here describes how this can be done for US numbers.
So I need to programmatically receive text messages from a shortcode. Twilio does not support this. Anybody know a service like Twilio but that is able to receive SMS messages from a short code sender?
Just to be clear. I need to receive a text message from a shortcode to a 10 digit number, not send from a shortcode.
Most services (Twilio, call fire) that let you send from a shortcode can not receive a text message from a shortcode
This can’t be done, shortcodes are unique to each carrier network, when a short code is available across multiple carriers it is implemented on each carrier separatly.
Also shortcodes are not international so 54321 could be used in both the UK and US by totally separate services.
SMS providers like Twilio and Vonage connect to the carriers in the same way as the shortcodes do, they are both an application connection. The carriers do not permit app to app messaging through their network so a shortcode app will only ever be able to send to a real subscriber with a SIM card.
You might find some providers that offer an SMS API by using banks of hosted SIM cards but this can be very flakey and you are usually sharing the number. The other option might be to look at hosting your own SIM card in a usb single or such and recieve the SMS that way.
Actually, Twillio does support this now, although with a big disclaimer that it "cannot guarantee that every short code globally will be able to reach Twilio numbers"
https://support.twilio.com/hc/en-us/articles/223181668-Can-Twilio-numbers-receive-SMS-from-a-short-code-?_ga=2.202438166.641482548.1608644940-210958917.1588771372
I think this article might be just what you're looking for https://help.nexmo.com/hc/en-us/articles/216487658-Inbound-SMS-on-dedicated-US-short-code
You should be able to receive SMS messages on a dedicated US Shortcode.
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.
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.
How does one link a single twilio number to multiple phones such that:
When new people text the twilio number, all of the phones linked to the twilio number receive the text.
When any one of the twilio phones respond to the text, it appears to the original texter that a single number is responding to them (irregardless of which of the twilio phones sends the text).
Picture texts work also in the way described in (1)-(2).
This is very similar to what Google Voice can do, except google voice sometimes doesn't work with picture texts.
You would need a backend of some sort, where you can store subscribers for a number, you can then handle in your language of choice, when you receive a sms perhaps containing the word "subscribe", you would then simply save that into your backend along with the number that the sms was received upon.
When receiving a sms that contains other text, you would then simply query your backend and find all the numbers that have subscribed to the number that you have just received the sms on, you would then simply use the Twilio api, to send the message to all the results from your backend query.
You could also allow unsubscribe functionality, where users only have to send unsubscribe to the number, and you would remove them from your backend or flag them as to not send to them again.