For testing Twilio applications, Twilio provides test credentials. You are allowed to buy phone numbers through the API without being charged to your actual account. My application requires that I be able to buy multiple phone numbers. I would like to do this with test credentials.
However, per this documentation page, it seems like the only phone number you can buy is +15005550006. I tried buying other phone numbers, but I keep getting an exception that states that the phone number I'm trying to buy "...is not available."
Is it really the case that only that one number can be bought?
Twilio developer evangelist here.
Test credentials are for making sure your HTTP calls are being made correctly, they just mock the results of the API so you can make practice calls to it. The idea with test credentials is that if the API call to the fake number works, then your code will work in production.
The test credentials also cause Twilio to return special results for certain resources. For example, you can try to buy the number +15005550001 and it will tell you that the number is invalid. You can see the special examples here: https://www.twilio.com/docs/api/rest/test-credentials#test-incoming-phone-numbers-parameters-PhoneNumber
If you need to actually buy numbers with your account to build your application with, you'll need to use your live credentials. If your app is successful purchasing +15005550006 then you can be sure that switching out to real credentials will work.
Related
We have a query to ask regarding the Twilio voice communication and hope you will help us.
We are having a client and they are having business with Health care domain having Doctor-Patient communication happening through Twilio cloud.
We know that a non-twilio number can be used for caller id after verification with twilio by 6 digit input from the user.
The client requires a mechanism like when they sell the product to many customers, each customer just input any valid work number (office number) and wants to use those number as Caller Id without the verification process.
We would like to know whether Twilio us offering such custom caller ids without doing the verification steps ? Like with means of a high-level membership plan with twilio or for utlizing any bulk purchase schemes or by trusting the client with any documents or by any other means of ?
Please give your suggestions in this.
Thanks
No. You need to verify each number to use it for your caller ID. Another way of doing it is that you buy the number via Twilio when the customer signs up and that's their outbound caller ID. Would be much easier to do.
david
I'm confused on how exactly to verify a phone with Authy.
I have a C#/MVC view that accepts a country code and phone number and I call AuthyClient.RegisterUser and that works fine. I store the AuthyId that comes back.
I then call AuthyClient.SendSms with force=true. <--- does this send them a verification code?
My test user didn't even enter a code on my site and in Twilio, he's showing as verified. Is that because he opened up the Authy app after getting registered?
Are there multiple ways to verify a phone then?
Twilio developer evangelist here.
The API requests you are making here, starting with the call to AuthyClient.RegisterUser is actually the way that you perform two factor authentication with the Authy APIs.
To verify a phone with Authy you only need to make two API calls. The first sends a verification code and the second requires the user to input the code they received and then verifies it.
I can see you're using the authy.net library, which is sadly archived on GitHub now because it wasn't kept up to date. I'm not a .NET developer, but from what I can see in the codebase it didn't support the Verify endpoints. For this reason, I'd recommend you construct the HTTP requests yourself.
Take a read through the Verify documentation, it has all the URLs you need to make requests to including the required parameters. Let me know how you get on with that.
We're building integration with Twilio's Authy phone verification API at the moment.
The docs don't specifically say what happens in the case that malicious user sends lots of guesses to the verification/check endpoint while trying to verify the sms code.
I assume Authy must have something in place to prevent this, but it's not explicitly stated and I'm wondering if we need to build in some protection (e.g. guess-counter limit) in our own API integration code.
Twilio developer evangelist here.
There is a limit built into Authy for phone verification. There is a maximum of 5 attempts per verification code, to avoid brute forcing the code.
I'm trying to find out why this isn't documented, but in the meantime you should not have to build out protections yourself.
I am building a mobile-focused web application, to later convert to hybrid, and I would prefer new user registrations confirm the user's phone number versus their email address.
I would like to send a new user an SMS with a unique code. When they first log in, they must enter that code to activate their account.
I have a custom SMS service that is sending SMS fine, and would like to know how to integrate this into the Identity registration process.
Please note that I do not wish to use SMS for routine two-factor authentication.
You can use create additional actions in your account controller
and use methods from Microsoft.AspNet.Identity.Core
UserManager.GenerateChangePhoneNumberToken
Send sms with token
UserManager.VerifyChangePhoneNumberToken
Add custom logic to authorization
There are several ways to accomplish this.
Cheap but not reliable or enterprise ready is to build an app on a device you own and have those other devices send an SMS to it. You can process the SMS and reply however you like. With unlimited texting plans, it would be fine. It's just not redundant or reliable (the phone battery could die, you may need to do updates that could interrupt service, etc.)
Work with a company like Twilio (https://www.twilio.com/) and use their SMS gateway, API and services to build, quickly and cheaply (for the most part) the type of service you are looking to provide. There are competitors to Twilio and I'm not endorsing them, just providing them as an example.
Obtain your own SMS gateway (https://en.wikipedia.org/wiki/SMS_gateway) and then do heavily integrated and customized services.
If this is just a proof of concept at the enterprise level or you don't know what your user adoption rate will be, then #1 is probably fine until you need #2. #3 is rarely the best option.
Background
I use Twitter's Digits SDK in an app for sign-in, essentially allowing the Users to sign-in quickly use an existing (previously verified by a web app) mobile numbers. This has worked great during internal testing and everyone likes the feature.
Digits SDK
This is part of Twitter's Fabric SDK. It provides a view controller that appears, allows a User to type in a phone number, verify it with a 6-digit code sent via SMS, and it returns auth tokens, etc.
Problem
In order for Apple to review my app, I have to provide a phone number where an Apple employee can receive an SMS [from the Digits verification service] so to be able to authenticate and test my app.
Problem is, I've already tried a number of "Read SMS online" services, but none are receiving the codes from Twitter / Digits. Without a solution, I'm don't have a way for the Apple review team to get past the first menu of my app.
Any ideas? Thank you.