People Data API: Real-Time vs Monthly Batch

A people data API and a people search engine answer different questions, and the two get conflated constantly because both sit behind a single HTTP call that looks identical from the outside. A search engine finds candidates matching a filter. A people data API resolves one specific person, by an identifier you already hold, into a structured record: current title, employer, work history, education.

The identifier is what makes it tractable. A LinkedIn URL or username uniquely determines a person by construction, so there is no matching problem to solve, only a lookup, which is why this category can promise an exact answer rather than a probable one.

Every provider in this space lists roughly the same fields: name, title, company, location, education, work history. Comparing catalogs is close to useless because the catalogs converge. The question worth asking instead is when the record you get back was actually captured, and most vendor documentation makes that surprisingly hard to find.

The common pattern is a dataset refreshed on a monthly cycle from aggregated sources, sitting behind an API that responds in milliseconds and therefore feels real-time even though the underlying row can be weeks or months old. A `last_updated` field on the record helps, but only if you look at it: the endpoint itself gives no signal that a match came from a stale cache versus a current one, and a 200 response with a full profile object reads as fresh either way.

A single lookup by LinkedIn identifier looks like this. `linkedin_url`, `username`, and an internal `id` are interchangeable, once you have enriched a profile once, the returned `id` is the cheapest way to look the same person up again without re-parsing a URL:

A miss returns a plain 404. There is a separate, unmetered `/person/check` endpoint that answers only whether a record exists and how old it is, without spending a request against your enrichment quota, worth running first over a large list if you mainly want to know which identifiers are worth acting on.

The honest version of that claim is narrow: a record past a defined age is re-fetched from the live source before the response goes out, so a stale row never reaches the caller silently. Ours refreshes anything older than 90 days inline, on the detail lookup, before answering, which costs a couple of extra seconds on the small fraction of requests that hit it and nothing on the rest.

That is a different guarantee from "we crawl continuously" or "our data is always current," phrases that describe the ingestion pipeline's ambition rather than the age of the specific record a specific request returned. The only way to tell which one a vendor actually ships is to enrich the same identifier twice, a year apart if you can, and check whether the second `fetched_at` moved.

Most people data APIs price per credit, one deducted per successful match, sometimes per attempt regardless of outcome. That model rewards a provider for a high match rate on whatever population they choose to advertise it against, and it makes testing expensive: every evaluation call against your own list has a real cost, which quietly discourages the exact due diligence a buyer should be doing.

A flat monthly license removes that friction for a specific reason: the marginal cost of one more test lookup is zero, so there is no incentive to test against a small, convenient sample instead of the full list you actually care about. Kooperativa is priced at $499/mo per workspace, unlimited requests inside a shared rate limit, which is the model, not a pitch, worth naming because it is the reason the evaluation advice above ("test 100 of your own records first") costs you nothing to follow here and a noticeable amount to follow against a per-credit provider.