Dear you,
Happy Valentine's day, and here's our valentine to you! In this week's changelog series, I have a special gift worth $11326.67 for all our VC customers. Do read to the end for that!
Use the resolve_numeric_id parameter liberally!
We tweaked the resolve_numeric_id parameter with the Company Profile Endpoint, Employee Listing, and Employee Search endpoints to only consume credits if our API does actual work to convert the numerical ID to a vanity ID.
Story time. The resolve_numeric_id parameter exists because LinkedIn decided to stop supporting LinkedIn Company Profiles linked via a company's numeric ID. That means public LinkedIn company profiles with URLs that looked like "https://www.linkedin.com/company/1281248" stopped loading. And that means our API would cease being able to fetch fresh data from LinkedIn profile URLs.
That very same day, we scrambled a quick fix in the form of resolve_numeric_id, and it was left as such. The parameter was a quick fix for which we brought back numeric ID support for company profiles on Proxycurl API in spite of LinkedIn's actions. (Another reason why you should use Proxycurl.)
A customer provided feedback that he was getting charged 2 extra credits for every API call to our Company Profile Endpoint because he had supplied the resolve_numeric_id=true parameter with every request. He was getting charged even though he was supplying LinkedIn Company Profile URLs with vanity IDs, and he was not happy.
I would if I were him. It just isn't a good user experience. So I took the feedback to the team, and we reworked the parameter so that you can supply the parameter liberally and only get charged if our API kicks in and do work.
So go ahead and use the resolve_numeric_id=true parameter for maximum compatibility from here on and you will not be charged credits unless we actually resolve numerical IDs!
Person Lookup improves (again)
We just tuned the Person Lookup API Endpoint again, and it should work better now.
Better parser for Person Profile Endpoint
We updated the parser for Person Profile Endpoint to:
- Extract the last name properly.
- Fetch dates in the
cs_CZlocale correctly.
There were some errors with the Person Profile Endpoint because one of our data sources is public LinkedIn profiles. Given that LinkedIn is a moving target, we have to play the cat-and-mouse game constantly with them. And really, this is what you are paying us for -- an API that just works most of the time. And when it doesn't, we will fix it, so you don't have to.
UI tweaks
Slight tweak, but we muted the colors in the new dashboard. Personally, I couldn't stand how contrasty the new dashboard was. So I got my team to mute the colors and only use contrasty colors to highlight the call-to-actions that matter.
Layoff Data Pack
We built a data pack of ex-Googlers who got laid off recently. This data pack costs $11326.67 if extracted from our API, is freshly updated, and includes data such as
- ex-Googlers who founded new (stealth) startups,
- which startups hired the most ex-Googlers, etc.
If you are a VC or an editor at an established media site, I will be happy to give you the data pack in exchange for a tweet. Send us an email at [email protected] if you are interested!
We built this data pack because Google laid off a bunch of people recently, and we wanted to find out the story behind these layoffs. To understand the story, we fetched all of Google's employees (with Employee Listing API), refreshed it (with Person profile Endpoint), and found out who was laid off.
This data pack contains the following:
- All present employees at Google (so you can continually monitor them).
- All recent layoffs at Google.
We have more data packs coming.
Google's layoff data pack is landing this week. We will also be doing the same for Amazon, Meta, and Netflix. I want to give them to you in exchange for a tweet (if you are a VC or an editor).
I will also be sharing a lot more about what's up at Proxycurl. Why don't you subscribe to our newsletter so I will send you this info? Oh, also, follow us on Twitter!
