Volunteer-based nonprofit that has already saved one life. "Our raiding parties (volunteers) give their time, energy, and care to provide support, practical help, wellness guidance, and social connection. We’re here because cancer should never feel like a solo battle."
We're always happy to see more companies set up shop in this space. It helps to keep us on our toes.
At first blush, it seems that EveryoneAPI is focused primarily on phone numbers. Conversely, our focus with FullContact is much more in line with social profile and public social data. Though you certainly can query the FullContact Person API via a phone number, that's never been our primary focus.
With relation to the comment about speed, it's worth noting that greater than 95% of Person API queries are returned in 30ms or less. But to the end user, depending upon where they are hosted, network latency can play a large role in the actual response time, which is a factor for any http based API traffic.
Like EveryoneAPI, we prefer to compete on merit rather than slinging mud. If you have a project that you're building, I'd love to see how we can help. Our APIs are always free to get started, so you can see your results before ever having to pay.
Telo isn't new to this space. OpenCNAM has been around for nearly 5 years and EveryoneAPI was launched a year ago. We have just been doing some updates and now offer a free $0.50 trial.
Record availability probably would have been a better way to phrase it rather than speed. While I am not familiar with the latency of the FullContact API, I have experience a sort of fulfillment period (come back later) for records that require more sourcing efforts. That is unless that has changed. We focus on real-time responses that span nearly the entire NANPA dialing plan (US, Canada, Caribbean and part of Central America). In terms of the data-points and focus you are correct that our focus is on the data associated with the phone number query. We do plan to expand our phone coverage to international dialing plans outside of NANPA (NPA-NXX-XXXX) by the end of the year and will be offering a forward append service for name and address as well.
Update - we've updated the extension to support Gmail Right-Side Chat. To get the new version immediately, you'll need to force an update to the extension.
We love Vibe. It's a great app and carries a lot of the same features. I think that the advantage of using FullContact for Gmail is being able to interact with your FullContact address book, and then automatically sync that information back to your Google Contacts. But ultimately, it's whatever works best for you. We know that the Vibe team shares our passion for making you awesome with people, and we're happy that they're making great products.
What are your plans for an Android app, for synching/sharing contacts between gmail and GAE accounts, and for linking to or integrating with social networks?
iOS and Mac apps are coming next, while we perfect Android compatibility. We're also working on contact sharing among accounts. It's our biggest request, and we want to make sure it's right. As for social networks, we already integrate with a number of them. What would you like to see?
As long as you cover LinkedIn, Facebook, and twitter, I'm good. Then again, GitHub could be good too.
Good to hear about contact sharing/syncing. Ideally, I'd contacts added in either my gmail (personal) or my GAE (business) accounts to be available to both [1], and for contacts to be tagged as personal or business depending on where they were added.
[1] Right now, they are available to both on my phone (Android), but not on the web. This is a real pain. For historical reasons, the vast majority of my contacts are in my personal gmail account, but there are great many I use primarily in my GAE business account, and quite a few I use in both, depending on why I am conversing with someone (I keep personal and business emails as separate as I possibly can; just the way I like to do things).
That level of sharing/syncing is my killer feature.
Having said that, I am so used to using Contacts+ for messaging, making phone calls, writing short FB updates, etc., that I would miss those features if I switched to your app.
Just tried it, looks good! However, my main gmail client is currently Google Inbox, do you have any plans of enabling the addon for Inbox in the future?
I only use Rapportive for occasional prospecting (e.g. the 'hack' where you keep trying an email combo until the person's LinkedIn profile appears, thus verifying the email address).
If this isn't available via your new add-on, would love to see it in there.
CardMunch still (for the next few days anyway) uses real people. That didn't change when the company moved under LinkedIn. Unfortunately there was an opportunity there that was never really seized.
As for how we compare? That's a matter of personal preference.
While I like Evernote a lot, and use it daily, it's just not where I want to store my contacts. Nothing about that makes sense to me. My contacts need to be where they're the most accessible, from the device that I'm going to use to get in touch with them.
I don't use a CRM, but if I did, I'd want to scan cards into it because that's where it makes sense for those contacts to live. I'd want to segment them and I'd want to pull them into my phone when I needed them. None of these things are easy to do when you use Evernote as your repository. It's great for being your "second brain", but not so great for being your phone book.
The big thing to mention here is that we don't use OCR, we use real people. It's the main differentiator (aside from the Zapier integration) between Card Reader and just about every other alternative. Yes, it's slower, but it's also incredibly accurate. And really, when was the last time that you scanned in a business card and needed the information from it 20 seconds later?
Because we use real people to transcribe the cards, we found that we were having trouble with accuracy when the cards are in languages other than English. As such, we flagged the app to countries that have English the primary language.
As we scale the app, we're going to enable more countries. But right now we wanted to make sure that we're providing the best possible experience, even if that means to a smaller base of users.
Hey there. Thanks for the heads up. That definitely shouldn't be happening, considering that we test on a Nexus 4. We're taking a look now to see what's up.
Privacy is a line that will always move, and it's different for every person. One of the biggest challenges that we face is finding a line that works well for everyone, while allowing them to control where that line sits.
As to your second point, sure, we'd love to have people use FullContact. But the post points to many more options than just our own:
"If that’s iCloud, Google Contacts, Outlook.com or heck, even FullContact, great."
As I said in the post, we just want people to use a safe system that makes sense to them. It's our job to make sure that FullContact is the logical choice.
The article did a good job IMO of pointing out the absurdity of LinkedIn's position (but I didn't need any convincing; I work at Nutshell, and contributed to the blog post you linked).
At this point in the pipe, it's not about privacy concerns; this is data available via the end user's use of LinkedIn. The salient question to me is, what the hell can we do with the LinkedIn API? Why even have developer.linkedin.com if your partner program is designed to exclude everyone but two companies? (A simplification that focuses on the CRM program, but I don't know what the purpose of their other Partner Programs are.)
>As I said in the post, we just want people to use a safe system that makes sense to them.
So going from a platform where random developers don't have access to _all_ of my contact info to one where they do is safer, in your opinion?
I get that you are trying to produce a better developer API, but I don't think users have any more control over their data with your product than they do with LinkedIn. Now they're just at the mercy of a different company's business decisions, which is how it will be in the majority of cases, as I see it.
