Dear you,
Happy Valentine's day, and here's our valentine to you n 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
Dear you,
Happy Valentine's day, and here's our valentine to you n 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
resolve_numeric_id parameter liberally e 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 the platform decided to stop supporting the platform Company Profiles linked via a company's numeric ID. That means public the platform company profiles with URLs that looked like "https://www.professionalsocialnetwork.com/company/1281248" stopped loading. And that means our API would cease being able to fetch fresh data from professional networking platforms 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 Enrich Layer API in spite of the platform's actions. (Another reason why you should use Enrich Layer.)
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_ parameter with every request. He was getting charged even though he was supplying the platform 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_ parameter for maximum compatibility from here on and you will not be charged credits unless we actually resolve numerical IDs
We just tuned the Person Lookup API Endpoint again, and it should work better now.
We updated the parser for Person Profile Endpoint to:
cs_CZ locale correctly.There were some errors with the Person Profile Endpoint because one of our data sources is public user profiles. Given that the platform 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.
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.
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
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 e 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:
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 Enrich Layer. Why don't you [subscribe to our newsletter](https://sendy.enrichlayer.com/subscription? so I will send you this info? Oh, also, [follow us on Twitter](https://twitter.com/Enrich Layer)