Enrichment vs. Search: Two API Shapes, One Decision

Enrichment and search are the two shapes a data API can take. Enrichment starts from a key you already hold, an email or a domain, and returns the full record for that one entity. Search starts from criteria and returns every matching record. The decision turns on one question: do you already know which record you need?

01What Are Enrichment and Search APIs?

An enrichment API takes an identifier you already have and returns the full profile behind it. Feed it an email address and you get back the person: role, company, seniority, location, and the rest of the 250+ fields we keep per record. A search API works in reverse. You describe what you are looking for, companies in a region of a certain size, people with a job title in an industry, and it returns every record that fits. Same dataset, opposite directions of travel: one walks from a key to a record, the other walks from criteria to a list.

02How to Choose Between Enrichment and Search

1. 01Write down what you have, not what you want: An email address, a domain, a name and company? That is a key. A description like "fintech companies in Texas with 50 to 200 employees"? That is the criteria.
2. 02Key in hand means enrichment: A key points at exactly one entity, and enrichment resolves it to the full record in one call.
3. 03Criteria in hand means search: No key exists yet, so the job is to generate the list first. Search returns matching records, paged, which you then keep or enrich.
4. 04Check the volume: One lookup at form-fill time is an enrichment job. Fifty thousand emails to refresh is a batch enrichment job. A market map of every logistics company in Europe is a search job, then a bulk export.
5. 05Prototype the real task, not the toy version: Run one actual workflow through both shapes before committing. The API that feels right on a sample of ten records often shows its limits at ten thousand.

03Enrichment vs. Search

04Key Benefits of Choosing the Right API Shape

You stop paying the wrong cost. Enrichment burns a call per key, so feeding it a criteria-shaped problem means guessing keys and paying for misses. Search returns records, so pointing it at a key-shaped problem means filtering down to one row you could have fetched directly. Matching the shape to the workload removes the waste.

Freshness means different things in each direction. An enrichment call is only as good as the record behind the key, which is why hourly refresh matters at the moment of the call. A search result is only as good as how much of the dataset the query saw, which is why the full index matters more than the single record.

The two shapes compose. The mature pattern is search to build the universe, then enrichment or bulk export to work it. Teams that treat the choice as permanent end up forcing one API to do both jobs badly.

One license should cover both. At MixRank, enrichment and search are both included in the same flat price, so the decision here is purely architectural. If a vendor prices the two shapes differently, that difference will quietly push your design in one direction regardless of what your workload wants.

05Bottom Line

The two API shapes are not competitors. Enrichment resolves keys you already hold, search finds records you have not met yet, and most real pipelines need both at different stages. Decide from the input you have, not from which API you tried first. If your vendor charges differently for the two shapes, the architecture was decided for you before you wrote a line of code.

MixRank keeps the decision yours. Enrichment and search both come with the same flat license, over the same hourly-refreshed data: 1.20B+ people profiles and 120M+ companies. Get started with whichever shape the task calls for, and switch when the workload does, without renegotiating anything.