RevOps Data API: Bulk Enrichment, No Forecast
For RevOps and data teams maintaining a warehouse, CRM, or internal database of people and company records.
| Endpoint | Returns |
|---|---|
POST /v1/people/bulk | Up to 500 profiles enriched per call, for large warehouse backfills |
POST /v1/people/bulk-enrich | Up to 100 profiles per call, mixed identifier types, for messier incoming data |
POST /v1/companies/search | Company records matched by name, industry, headcount, or location, for entity resolution |
GET /v1/company | A single canonical company record to resolve duplicate or partial entries against |
POST /v1/monitors | A signed webhook so records already backfilled don't silently go stale again |
A RevOps or data team maintaining a warehouse of people and company records usually runs two different jobs against an enrichment API: a large, occasional backfill of existing records, and an ongoing trickle of newly arriving ones. Credit-based pricing forces a forecast for both before running either, since the wrong estimate means either paying for unused credits or hitting a wall mid-backfill.
/v1/people/bulk (up to 500 profiles per call, by internal ID) is built for the first case, a full warehouse pass where records are already resolved to a known identifier. /v1/people/bulk-enrich (up to 100 profiles, mixed id/username/linkedin_url per entry) fits the second, an incoming batch where identifiers aren't uniform yet.
Resolving duplicates before they compound
The same company arriving from three different upstream systems, a CRM, a marketing tool, a billing system, is a common source of warehouse duplication. /v1/companies/search and /v1/company give a way to resolve an inbound company name or partial record against a single canonical entry (by linkedin_url, username, company_id, or internal id) before it gets written into the warehouse as a fourth, slightly different version of the same company.
Why flat pricing changes the backfill math specifically
A backfill job against, say, 200,000 existing warehouse rows is exactly the workload that breaks a per-credit budget: the bill is entirely a function of how many rows you have, not how much value the enrichment adds. On a flat license, running that backfill costs nothing beyond what the license already covers, and the same is true of running it again next quarter to catch drift, without needing to justify a new credit purchase each time.
Once the backfill is done, /v1/monitors is the mechanism that keeps it from needing to be re-run wholesale again: subscribing the records that matter most (executives, key accounts) means a job or title change flows back automatically rather than only being caught on the next scheduled backfill.
curl -X POST "https://kooperativa.io/api/v1/people/bulk" \
-H "Authorization: Bearer ik_live_..." \
-H "Content-Type: application/json" \
-d '{ "ids": ["f9413465-...", "a2c81e90-...", "..."] }'Get started
Try Kooperativa
One API key. Every endpoint on this page, and every other one, included on the same flat license with unlimited requests.