So to help debug we even take it out of our code and put it on twilio portal that lets us test the API. When I send to most of our group everyone gets the text message, but when we send to someone with tmobile, the message says it's delivered on twilio logs, but the person never gets it.
If we test and send him an 'Hello world' message, he gets it, but when we test with out SMS
'XXXXXX wants to make plans with you on the HotSauce App. :tada::hot_pepper:
Get the app now to join in on the action. https://rts2t.app.goo.gl/FGYB'
The message doesn't get delivered. Maybe there's a whitelist for Tmobile we can get on?
FYI, we have a USA number and this is a USA person and we are on the paid version, not trial.
I've encountered the same issue working on another app, and unfortunately I do not think there's a conclusive single answer. Carriers intentionally keep their spam filtering techniques secret so that they cannot be gamed. From Twilio's support page on the topic:
There is no standard practice for carrier filtering across all carriers. For some, filtering can range from a simple static list of prohibited terms to advanced machine learning systems that work in real time. Regardless of the system, carriers keep their filtering systems closely guarded secrets. In turn, Twilio cannot say definitively how these systems work or why a particular message was filtered.
Note that not all carriers report errors to Twilio, so some messages may appear to go through even though they were not delivered. You may or may not see error 30007 in the Twilio console when a message is blocked.
I don't believe any type of universal white-list exists, and once a number has been black-listed by a carrier there is no easy process to have it white-listed. However, short-code numbers are generally less prone to getting spam filtered (though they are more expensive).
While there isn't any one thing you can do to guarantee delivery, there are several things you can try:
Make the language of the text message more conversational as opposed to promotional
Don't obscure the url with a link shortener
Don't over-use a single number by implementing something like Twilio co-pilot
Include clear opt-out instructions
Related
What we are trying to do
I am working on automation which posts messages to a Slack channel using Incoming Webhooks on a custom Slack App. The messages mentions people.
What works
We can send a message just fine, it has formatted content, and usernames are correctly resolved using the link-names flag.
What isn't working
The whole point of the notification is to inform a dynamic set of people about something they should care about. The set of people we tag varies hugely (think people who contributed to a pull request) and so not all possible recipients are in the channel these automated messages go to.
We assumed that given the usernames are being directly #-mentioned, they would be notified by Slack. However, two of the users we've tested with and #-mentioned confirm they never received a notification they had been tagged.
This is different to "human" behaviour, where if you #-mention someone in Slack, you get a little message reminding you that person isn't in this channel and offers to invite them or let them know.
As far as we can tell, sending the message programmatically is doing the equivalent of "Do nothing" in the picture above. I want to do either of the other two options, preferably "Let them know".
How can I notify people they've been mentioned? I've looked at all the API documentation and nothing discusses notifying users who aren't in the channel that they are mentioned.
This can't be an uncommon issue.... right?
Notes:
We aren't directly calling chat.postMessage, it's just the only documentation on link_names I could find to link to. We are using Incoming Webhooks, which has minimal documentation on the parameters - it seems to be the same as chat.postMessage.
We would prefer not to move off Incoming Webhooks, but we can do a custom integration with the API if we have to.
You need to invite the user to the channel first, using the Python client that's:
client.channels_invite(
channel=channel_id,
user=user_id
)
I always relied on the "Carrier type" of "mobile" using the lookups API to determine if a number was able to receive a text message. This as served me well for several years.
I recently came across a lookup result as follows:
CARRIER NAME Enflick - 360 Networks - SVR
CARRIER TYPE voip
It seems this belong to the textnow.com carrier that sells wifi only phone plans that allow texting. Because of this, it seems some "voip" carriers can receive texts.
Is there a way to determine which numbers should be eligible to receive texts using the Twilio lookups API or something similar? I'd hate to consider all voip carriers as texting eligible since that definitely isn't the case.
Twilio developer evangelist here.
I think the easiest way to check if a number can receive texts from Twilio is to try sending one. If the API responds with an error (likely 21612) then you can't send messages to it.
I have a web application that sends verification codes to users through clickatell. Nearly all users are in the US, and those work fine, but I have about 5 with international phone numbers who receive no texts.
I have a page set up to accept delivery notifications and dump them into a log file.
If I send a message to a US number, like +18161234567 I get a notification like so:
integrationName=MyIntegration&messageId=*******************&clientMessageId=&to=18161234567&from=1##########&status=DELIVERED_TO_GATEWAY&statusDesc=DELIVERED_TO_GATEWAY×tamp=1502911816000
But if I send a message to a non-US number, like +393921234567, I get no response from the clickatell server at all. It's like they don't even get the request. The phone number is the only difference between the two requests.
I have a case open with clickatell support but they have been less than insightful so far, just telling me they need a messageID or error code to investigate further, but since I get no response, I have none to give them.
Has anyone else experienced this or have any ideas I can use to troubleshoot?
We have a two-way number because that is required for sending texts in the US. However, clickatell notes on the two-way settings page that
If the country does not support two-way messaging, Clickatell will not submit the message (you will not be charged for messages that aren't successfully submitted)
I can't seem to find a list of countries that do or do not support two-way messaging. Do I need to add a separate integration without two-way messaging to support my international numbers?
UPDATE: Upon further research, my international users are in 3 countries. Italy, which does not support two-way messaging, and France and Mexico, both of which do support it. Yet none of the three are working.
FURTHER UPDATE: I have tried creating a separate integration just for Italy, since they do not support two-way messaging. I have set it up to use the clickatell automatic mobile number formatting for that country. The result is the same. No text is sent and I receive no response of any kind from the server.
Can you please check/provide response from server when you submit message with number: +393921234567.
Most likely you get validation error - that this destination number not covered by number that you bought.
Have a nice day.
I am making an event organisation platform. Whenever user creates an event, the candidate gets an email notification as well as sms notification asking whether the suggested time fits or not. The problem is that since it is event organisation, there may be more than one occurance of candidate's mobile phone. So I need to have some unique information to identify to which event candidate is responding to.
I have tried identify using Message SID, but then I realised that Message SID is different on reply message.
So my question would be: is there any way to authenticate to which message candidate is replying to?
Hi Twilio developer evangelist here.
Because every message is idempotent, you wouldn't be able to track them just via the call sid. however, there's way to get around that such as passing a code that goes with each message which you can then read, or using cookies.
I think you are probably going to be more successful using cookies, and luckily enough there is an article on twilio's website that describes just how to do that. And because I noticed you're using PHP, I'm pointing you directly to the PHP article on tracking SMS conversations.
Hope this helps you
I am trying out different things with Twilio, but open for other solutions with Nexmo, Tropo or Plivo.
Here's a situation, I am sending an SMS texts from a server to bunch of clients. I can get a status back: like queued, sending, sent, or failed. Here's what Twilio says about SMS sent status:
"Sent" indicates that your message was successfully sent into the SMS
network for delivery. However Twilio does not receive confirmation from
the destination carrier that the message was received, and this is not
a guarantee that the message has reached the intended device.
(https://www.twilio.com/help/faq/sms/what-do-the-sms-statuses-mean)
So, my question is: does Plivo, Tropo or Nexmo (or any other service that I missed) do anything like that? I mean, knowing that an SMS was received either by client directly, or client's carrier would be really important.
PS. I'm not even sure if it is possible
Any help or suggestions would be appreciated.
It's certainly possible with Nexmo - as the other answer and comment state, it's not possible with Twilio & Tropo. Plivo's docs look like their delivery receipts are similar to Nexmo's.
Nexmo sends a delivery receipt if it's supported by the carrier. In the US it's not, but internationally it is supported often. In those cases Nexmo will give your app a callback with a delivery receipt. You can also use the message ID to query for the message status.
This screencast shows checking the DLR from the dashboard, which is really just a UI on top of the API.
Kevin makes the point that this could be difficult if the message is bounced through multiple providers - one of Nexmo's focuses is getting as direct a connection as possible.
[Disclaimer: I do occasional developer evangelism for Nexmo.]
I'm a Tropo customer, and I've asked the same question, and so far, the answer's similar to what Kevin Burke gave for Twilio. It's hard to do, so there's no confirmation at this time. They do give some debugging information in the logs which is helpful with that first-hop negotiation, at least, even if it's hard to retrieve/parse easily. They are working on it, and have been very active adding new features.