I am using an Identity and Access Management(IAM) vendor who provide a Multi-Factor Authentication (MFA) Service (using SMS and other channels). They use Twilio as their SMS service provider and what I see currently is a behaviour (described in the scenario below) from my IAM provider which is strange and wondering what the underlying Twilio API's behavior is.
I am unable to see this info from the Twilio API docs hence seeking assistance.
Scenario:
Customer uses IAM to login and my IAM provider using Twilio sends a OTP
The OTP comes through but in my test case, I trigger the resend OTP process
In both the steps, I get the right message (the template and senderID that we have configured in the IAM tool)
If I now trigger the OTP resend process a second time (3rd OTP in total for the same number), we receive a message which has AUTHMSG as the senderid and uses a default template message (which is different from what we have configured).
I am working with my IAM vendor to understand what is happening here and I am trying to see if Twilio is playing a part in this (trying to do some smarts as they think that there is some SMS delivery issue - which is the message I am in a way communicating by hitting the resend OTP multiple times)
Is AUTHMSG a senderID that is owned by Twilio? I don't believe so but I am trying to better understand this space.
SenderID is a construct that varies from country to country. Some Contries mandate that users register it with the local regulators while in other countries there is no explicit registration process.
I am worried that if my customers receive this message, they are going to be confused and suspect a Spam/Phishing kind of an activity.
I attempted a similar exercise with PayPal and they were consistent in their SMS OTP Resend. The message was always the same. Unlike my IAM provider, PayPal sends OTP from multiple mobile numbers. In my tests I observed them sending OTPs from two distinct mobile numbers.
Would be glad if someone could assist and provide info in this space.
I will continue to work with my IAM provider and their support channel to see what is happening here.
When using Twilio Verify in a country that supports alphanumeric sender IDs, Twilio uses the AUTHMSG sender ID and registers it with countries around the world that require this, to ensure the best deliverability of OTP messages.
I think you will need to work with your IAM provider, and work out how they have implemented sending OTP messages to see what is going on here. If it is unclear, then you or the IAM provider may also have to contact Twilio support.
Related
I have successfully set up a DM bot with the Account Activity API. Everything works very well, except that sometimes the message sent to the bot (through the Twitter's web interface or mobile application) doesn’t fire a webhook to my server. The messages could be quick replies responses or plain text.
The reason is obviously not a downtime of my server since I tried to make a conversation between 2 webhook registered users (so my server receive the webhooks for both users) and for the same message sent, I have successfully received the webhook of the sender (the user) but not for the recipient (the bot).
As the bot isn’t in production yet, the reason is not an overload of messages. There is currently only 2 users that make conversations. From my experience, around 10% of messages are "lost".
I'm using the free (sandbox) Account Activity API tier, but as I understand the only differences between the free and paid versions are a higher number of subscriptions (I'm fine with 15) and the “Retries” feature. Regarding this feature, it is specified that “The Account Activity API provides a retry feature when the client’s web app does not return a ‘success’ 200 response for an account activity webhook event.”
It clearly states that the event failure concerns the client’s side, not the Twitter side. Considering this issue (my server doesn't receive the webhook at all), there is no guarantee that every event will be delivered even if in a paid plan.
This is a big inconvenience for bots since a button can only be clicked once, so the user must retry the conversation from the beginning (besides the fact that the bot "doesn't work"...)
So my questions are :
Is anyone here experience this issue ?
Is this a “bug or a feature” of the free Account Activity API ? I mean, at random the free tier doesn't fire the webhook on purpose (even if it's not specified in the docs) ?
Is there a way to see or measure the webhook failures Twitter side, via the dashboard for instance ?
A guess is that the events could be more accurate if the account is verified (with a blue badge) or hit a followers number threshold ? The treatment could be different due to the potential surge of events, so they are monitored with more ressources, thus more reliable ?
I already create a topic in the official Twitter forum and there is at least one other person in the same case, but no official answer from Twitter so far.
Thanks a lot !
BR,
Simon
I've got an official answer from Twitter :
Unfortunately it is not possible to achieve 100% delivery rate when there is only 1 delivery attempt for an event, which is why we have retries (and even then, retries are not a guarantee either). Things can go wrong; maybe internal issues in Twitter Data Centers, routing issues in the internet, hosting issues at your webhook, etc.
So from the time being, it seems that there's not way to have a 100% success delivery when you build a bot on Twitter.
Full answer can be read here.
I'm applying from Twilio to use their WhatsApp API service they are providing to build a WhatsApp auto-reply bot. But the problem here is that they want us to use the phone number they provide to us which we need to buy from them.
I tried using the URL 'https://api.whatsapp.com/send?phone=15551234567' but it just redirects to a page to send a message which I need to click 'Send' in order for it to submit our message. Besides that, we need to be able to trigger the application that a message is received from a recipient so we still need to access the API.
So how exactly is it I want to build a Whatsapp Auto Reply service to the public if Twilio provides it's own phone number only to reply. I want to reply using phone numbers that my clients register with me which is their own phone numbers.
As we know Whatsapp API is not open for public but how other Whatsapp Auto Reply apps are able to use our phone number to auto-reply to our recipients?
Would love some feedback or solutions from StackOverflow community. Thanks.
Twilio developer evangelist here.
Currently the Twilio documentation on using numbers on WhatsApp says:
Currently, we are unable to enable WhatsApp on non-Twilio numbers; support for this is coming soon and we will update these docs once available.
So this is just a current limitation and will be changed in the future.
So I am testing out Dialogflow and one of the first questions I have is: how does my bot know who it is talking to? I need to identify a user and keep that information for as long as I can. The basic scenario being:
User starts his/her first conversation.
Chatbot send a fulfillment request to the server trying to match a user within its own database.
The user is found, the information (as a JWT or some other token) is sent back to Dialogflow and stored there for further communication. In reality, this part would involve asking for user email, sending a verification code to that email and then verifying the user with the code.
User then starts chatting with a bot and all fulfillment requests get the unique token stored for this very user, so that my REST API knows which user is being served with the response.
Couldn't find anything about it in the docs (maybe I am looking in the wrong places).
There will be several integrations, like Messenger, Viber, Telegram. I dunno, maybe those APIs add some unique information on the user?...
Thanks for the help!
Sorry, I know it's been a while, but maybe this will help someone else.
The right solution here is a user id, not a session id. A user id is provided by the chat platform (Facebook, Slack etc) and is consistent across sessions for the same user.
To get the user id, go to the Fulfillment tab, enable the editor and use a function like so:
let r = request.body.originalDetectIntentRequest
//this makes sure that you're on an integration
if (r["source"]){
return r.payload.data.sender.id;
}
To tie together ids from different platforms, you probably have to have some kind of log-in process every time you encounter a new id on a platform.
Pop,
Sessions are built in already into DialogFlow requests to your fulfilment service, if you check the payload you will find a sessionId, it remains the same for the same client until it expires.
However if you want to identify the user from any of the clients that you can connect to DialogFlow like Messenger then from the same request payload to you you will notice that there is an object named originalRequest that is only available when requests are coming from those clients.
You can personalize those users response eg using their FB firstname in a message to them.
For Google cloud messaging, is there a use for storing the token? Or can we just work with the registration id? Trying to setup push notifications and was wondering why they use both tokens and registration ids.
Use the token on your server, to specify the device you want to send a message to. You, as a developer, have no significant use for the registrationID, in terms of actually sending the message.
From my understanding, token is used to authorize your application' access to Google Service while registration id is the unique identifier of an app on a specific device. GCM uses Registration ID to identify the device and app to send push notification to. So to answer your question, you need both of them.
This is an authentication flow, which logs in the user with only the phone number provided (Whatsapp style). The Steps are:
User enters phone number and sent to server.
Server generated 4 digit random key, and save the pair (phone,key) in DB.
Server asks 3rd party SMS service to send key to phone.
SMS service sends message.
User enters the key from sms, and together with phone, sent to server.
Server checks the pair against the DB.
If pair exists, server sends back a token for further calls.
What I am trying to understand is where services like Twilio and Nexmo fit in (or replace parts of the flow).
From what I understand, looking at Nexmo for example,
I can replace steps 2 and 3 with an API call to:
https://api.nexmo.com/verify/
and save the request_id from the response in the DB as pair (phone,request_id).
And now, when the user enters a 4 digit code and sends it back,
I need to call:
https://api.nexmo.com/verify/check/json
providing it with request_id and code.
But where do I get the request_id?
Do the server needs to send it back to the client, the moment it gets it from Nexmo?
I can't see the benefits of using Nexmo here, what will it save me?
Answer to your first question: the request_id is part of the response to the first verify API call. See: https://docs.nexmo.com/index.php/verify/verify
As to what are the benefits of Nexmo here, I believe you have two options:
Generate your own code, use Nexmo to text it to your user, have the user submit the code back to your application, verify code against your own database.
Use Nexmo verify service to generate and send the code to the user, store the returned request_id in your db, have user submit code to your application, call Nexmo verify API to validate code.
In some ways the first option is easier as it is less API calls. However the benefit of the second option, using Nexmo Verify, is that they provide a whole lot more capabilities into the service to fall back to a voice call if SMS isn't working, filter out virtual phone numbers to prevent spam, you don't have to pay for failed SMS attempts, reporting/analytics, etc. etc.
Hopefully that helps a little.