Show HN: Yolodex – real-time customer enrichment API
api.yolodex.aihey hn, i’ve been working on an api to make it easy to know who your customers are, i would love your feedback.
what it does
send an email address, the api returns a json profile built from public data, things like: name, country, age, occupation, company, social handles and interests.
It’s a single endpoint (you can hit this endpoint without auth to get a demo of what it looks like):
curl https://api.yolodex.ai/api/v1/email-enrichment \
--request POST \
--header 'Content-Type: application/json' \
--data '{"email": "john.smith@example.com"}'
why i built it / what’s different
i once built open source intelligence tooling to investigate financial crime but for a recent project i needed to find out more about some customers, i tried apollo, clearbit, lusha, clay, etc but i found:
1. outdated data - the data about was out-of-date and misleading, emails didn’t work, etc
2. dubious data - i found lots of data like personal mobile numbers that i’m pretty sure no-one shared publicly or knowingly opted into being sold on
3. aggressive pricing - monthly/annual commitments, large gaps between plans, pay the same for empty profiles
4. painful setup - hard to find the right api, set it up, test it out etc
i used knowledge from criminal investigations to build an api that uses some of the same research patterns and entity resolution to find standardized information about people that is:
1. real-time
2. public info only (osint)
3. transparent simple pricing
4. 1 min to setup
what i’d love feedback on
* speed: are responses fast enough? would you trade-off speed for better data coverage?
* coverage: which fields will you use (or others you need)?
* pricing: is the pricing model sane?
* use-cases: what you need this type data for (i.e. example use cases)?
* accuracy: any examples where i got it badly wrong?
happy to answer technical questions in the thread and give more free credits to help anyone test
hit the curl. ~800ms TTFB.
if this is truly "real-time" and not a cached graph, how do you handle rate limiting and CAPTCHAs at scale? Even with "public" data, on-demand scraping usually requires massive residential proxy rotation which eats that $0.03 margin alive.
thanks for giving it a go!
if you tried the curl command then yes this is indeed fast. the example curl command is hardcoded, john.smith@example.com is used with a static response for the purposes of allowing users to test the shape of the api without needing to be authed. low time to first test was my aim.
keen to hear if you have a use case for something like this?