My customers are not receiving SMS to verify their OTP. We have integrated Twilio with Parse and is using it for OTP Authentication. We are based out of India.
We faced this during test account. It never used to send SMS in the night and received all SMS next day morning. Now we are using a paid account and still the same issue i.e. my customer did not get any SMS during night and also not in the morning. Kindly help.
We will not be able to do business if our customers do not receive OTP SMS.
Is this a known issue ?
India is difficult to get text messages to, there are lots of rules and restrictions
Completed a project recently using a Twilio competitor (Clickatell) and it was the very same problem.
Frow Twilio's website:
Are there limitations on sending SMS messages to Indian mobile devices?
3. They are only delivered between the hours of 9 A.M. and 9 P.M. local Indian time
If you’ve been seeing delivery delays when sending to Indian numbers,
make sure you are making the requests during the operational hours of
9 A.M. to 9 P.M., as overnight messages are likely to be cached until
the next day.
https://www.twilio.com/help/faq/sms/are-there-limitations-on-sending-sms-messages-to-indian-mobile-devices
As E.J. said above, India has a lot of regulations to follow when sending SMS.
This is not a Twilio specific issue.. Other SMS APIs will have the same outcome.
For example, as stated on Nexmo's Country Specific Rules & Regulations webpage:
"We can only guarantee message delivery between 9am to 9pm. Messages submitted after 9pm we will attempt to send, but due to local regulations, these messages will be queued until the morning and you will be charged for them as usual."
Here is some more in-detailed information: India: Features & Restrictions
Related
Our product (SaaS) has a function that connects to Microsoft365. When a user creates an event with meeting rooms on Outlook, our service detects it and writes some messages in the event using Graph API.
On March 30th, 2022, Microsoft365 suddenly started sending many emails. They describe that the meeting room accepted the request. It's ok if we receive an email once, but we receive them about 5 to 10 times in some minutes.
Without our service, we don't receive many emails, only once.
We didn't update our service on that day, so we have been confused about it.
We got audit logs from our Microsoft365 admin, and it shows that the event was updated many times by the Microsoft365 server itself (not by our service).
We are wondering what is happening. Does someone have any ideas?
Thanks.
We've been using Outlook's streaming service for emails and events for about a month and a half and haven't run into any issues. However, yesterday at around 6:45 PM Pacific Time I stopped receiving notifications for the email account: matthewbordas#outlook.com. There were no errors transmitted back to us and the stream kept reconnecting and the subscriptions weren't expired. This problem is still persisting to this moment, yet all our other user accounts are fine. I should add that this account has been used significantly for testing and the content of the emails sent to and from it have been gibberish; could the API blacklisted have it and marked it as spam? That's the only reasonable conclusion I can come to, but there isn't any documentation on this case and I haven't received any messages from Microsoft indicating that such a restriction was placed on the account. Any help would be greatly appreciated, thank you!
I set up a scheduling website at work which uses Twilio to send out sms messages with each person's next day assignment information as well as a link to the website where notes and everyone's next-day assignment is posted. Occasionally colleagues complain that they haven't received messages. Recently the problem has gotten much worse though is to be limited to people with AT&T and Sprint. People with Verizon and TMobile are get their messages without a problem.
A few more facts:
All of my code works well in testing and is consistent with Twilio's
instructions.
Twilio's logs list the messages as having been sent.
The people who's sms messages are not delivered tend to be at the end
of the alphabet
Anyone have any ideas what might be going on?
SMS messages the twilio logs show as sent which never arrive at the recipient's phone may be filtered by cell phone carriers as part of an effort to reduce spam sms messages. A website that sends out a batch of messages like the scheduling website you (I) describe may be particularly susceptible to such filtering since spam is also sent out in batches. The fact that recipients at the end of the alphabet tend to be blocked rather than those at the beginning might reflect an algorithm which flags earlier messages as suspicious and blocks subsequent ones that appear similar in that they contain the same website link.
In the past I was able to solve this problem by adding a 1 second delay between messages. That worked fine for my purposes. My site sent out the messages as a background job and with the 1 second delay about 25 sms messages get sent out over 2 minutes.
More recently AT&T and Sprint started blocking many more messages, though not all. At Jan 11, 15:04 PST, Twilio's status was aware of the problem and noted:
Identified - Messages with hyperlinks to goo.gl are being filtered on AT&T and Sprint. We are working with these carriers to address this filtering.
I was able to get around this problem by creating a shortened url using Bitly instead of Google's url shortening service.
Of note, Twilio is a great service but in the past their support folks were unaware that spam filtering could be blocking some of my sms messages. That's my prime motivation for posting about this issue here.
It seems that sites like mine can get caught in the crossfire between sms spammers and wireless carriers attempting to block them. Hopefully some day such sms spam filtering will get more sophisticated and stop blocking the messages sent by sites like mine.
I would love to hear if anyone with more sophisticated insight than mine has any comments.
Currently experiencing a really bad carrier filtering case through Twilio. Most messages sent to Verizon numbers are being blocked. According to Twilio support, Verizon recently implemented additional filtering methods to block A2P (Application-to-Peer) traffic.
Given this article: https://arstechnica.com/information-technology/2015/11/att-verizon-try-to-prevent-ban-on-text-message-blocking/ it seems like Verizon's more aggressive filtering might be related to the recent repeal of Net Neutrality, and their goal is to make more money by forcing businesses to get a short code.
If your using 10 digit phone numbers I Would also look at this
https://www.twilio.com/help/faq/short-codes/why-would-i-want-a-short-code-instead-of-sending-sms-from-a-regular-us-phone-number-or-phone-numbers
Long codes are meant for person-to-person communications, and can send only 1 message per second. For high-volume, application-driven messaging, Twilio recommends using a short code. Short codes can send SMS and MMS at 30 messages per second, and this high throughput is perfect for applications needing to send time-sensitive messages to many users at once. Furthermore, since carriers vet and approve all short codes for their intended use, they are not subject to carrier filtering or suspension for heavy traffic.
I got some errors about sending mails too quick in 15 minutes when sending mails.
It seems there is a speed limit of sending mails.
But how many mails can be sent in 15 minutes?
Is this a standard or private rule based on vendor?
It depends on both your mail service provider, and also the target system. For example gmail will let you send 500/1000 (or more) emails per day, per account depending on your agreement with them.
I'm working on an application that sends and receives SMS messages to and from its users. (Don't worry - it's not spam - every user of the app expects to send and receive these messages).
One key aspect of the app... If a user sends a message to the app, the app then sends that message out to every person on that user's "team". So, the app will be sending a receiving a pretty significant number of messages (I'm hoping for a few thousand users, and 5,000-10,000 SMS messages per day).
I've been experimenting with a number of options:
SMS to email
Connecting a mobile phone to my server
Contracting an SMS gateway
Option 1 is great, since it's free, but it's unreliable (apparently mobile providers queue these messages after SMS messages they can charge for, so they're frequently received late or lost)
Option 2 is also cheap, but the mobile phone can't keep up with the number of messages I'll be sending. Also, the mobile phone provider will consider this volume of messages excessive.
Option 3 is perfect, except that SMS gateway providers charge PER MESSAGE (usually $0.02-$0.06 per), which creates an impossible scaling problem. (Reminds me of the old business adage... "Sure we're losing money on every transaction, but we'll make it up in volume...")
So, long story short - how on EARTH did Twitter pull this off? They've been doing a similar thing (allowing users to exchange SMS messages with the app) since the beginning. Even if they negotiated an INCREDIBLE discount (say, $0.001 per message), they'd be paying an ENORMOUS cost to send the hundreds of millions of messages they handle.
Does anyone have any idea how they did this?
After a bit of Googling, it looks like Twitter has simply been signing deals with cell phone companies in various countries. For example (Twitter blog post link spam incoming):
Australia: http://blog.twitter.com/2009/12/sms-tweets-for-telstra-australia.html
Indonesia: http://blog.twitter.com/2009/11/sms-for-axis-indonesia.html
New Zealand: http://blog.twitter.com/2009/05/hello-new-zealand.html
UK: http://blog.twitter.com/2009/03/full-sms-service-for-vodafone-uk.html
Some more details about SMS in general here.