Rob from Twilio here - thanks for using the service. Localization and fraud/spam protection are definitely the two most useful for Twilio Lookup, but suspect there are a couple more than might be less obvious.
1) Smarter Routing - quite a few developers have expressed they'd like to know whether or not a phone number is a landline or not before attempting to send a text message. Twilio Lookup will describe whether the number is mobile, landline, or voip so you can choose the appropriate communication to reach the number.
2) Error Checking - While libraries like libphonenumber are useful for determining if a number can possibly exist, there are some conditions where determining if a number does exist is more valuable. This can be used for error checking - if I as a user input a typo in my phone number (e.g. I mistype my personal phone number as '(347) 193-6073' which does not exist instead of '(347) 923-6073')
I also suspect across larger applications carrier info might also contain useful demography. For example, knowing that your users in Montana mostly use Verizon might inform your advertising to surface more CDMA devices in that market.
Ultimately this will probably end up like every other product we release - the killer use case is one we never even considered.
Good feedback - appreciate you sharing. We do have geographic information with each webhook sharing city, state and zip - agree it would be useful to have this in the Lookup resources as well.
Are you able verify that the user's billing address is within a given area or return information related to that? nextdoor.com uses it to verify that you live where you say you do and I'd definitely pay to validate that information.
I don't think that'd be possible with [Local number portability](http://en.wikipedia.org/wiki/Local_number_portability). You can move your number anywhere, with a mobile number you can get a number anywhere, and with VoIP services, you don't even necessarily need to be in the US to get a US number. There's absolutely no way to verify the person actually lives where the number is supposed to be.
It would be based on the number itself. Obviously with local number portability this is not super accurate, but we do have some customers that find the data useful nevertheless.
I filed a support ticket the other day because I was curious, and this was the response I got:
```
Right now there are no plans to add this ability to this feature but I'm sure it's something we would look at as we go along. We really weren't sure this was a viable feature but enough people made noise so we developed it to help companies be more efficient when sending and calling the people they need to connect with.
```
Thanks Adam - we're rooting for you as you head out. Building a business serving developers is indeed as difficult as you say, but also - to be fair - an endless amount of fun.
Very kind of you to say Tim. They put in an enormous amount of work to be prepared to serve you in the field. Lot more preparation ahead, but stoked you found it helpful.
A fair concern. I think Task Router is less going up the food chain and more going up the stack - we're trying to provide more abstraction for the state common to all these problems as a pure platform.
My hope is all our customers can leverage these primitives to invest more development time in their applications rather than solve the same mundane problems over and over again. I think that's the promise of a continually improving platform rather than an elbow move.
I would agree with the characterization that it's moving up the stack... but it does seem to (without saying it explicitly -- not clear whether that's conscious or not) start to overlap heavily with an existing space [1]. How would you differentiate it from BPM / workflow tools (one open-source example being Activiti [2], but there are many in the market)?
