---
title: "Contact Enrichment API: Fields, Match Rates, Costs"
description: "A contact enrichment API returns a person record from one input key. Which key wins, what a published match rate hides, and the real cost. Start free."
canonical: "https://derrick-app.com/data-enrichment-api/contact-enrichment-api"
category: "Data Enrichment API"
updated: "2026-07-22"
---

# Contact Enrichment API: What You Send, What You Get Back, What You Pay

> A contact enrichment API takes one identifier for a person, an email, a profile URL, or a name plus a company domain, and returns a fuller record: identity attributes, professional attributes, then contact points. The input key you can supply for every row matters more than the vendor you pick, and a published match rate is only comparable once you know its denominator. Billing is the other decision that moves the invoice: per attempt charges every call, per result charges only what comes back. On 1,000 contacts at 60 percent resolution, that single choice is the difference between 3,000 and 5,000 credits.

*Canonical: https://derrick-app.com/data-enrichment-api/contact-enrichment-api* · *Data Enrichment API*

---

Every enrichment project starts with the same sentence: we have a list of people, and we don't know enough about them. A contact enrichment API is the machine you point at that problem. You send one identifier, it sends back a person record.

What decides whether the project works is almost never the endpoint. It's three questions that rarely get asked before integration: which input key you can actually supply for every row, what the vendor's match rate is measured against, and whether you are billed for the attempt or for the answer. Get those wrong and a technically clean integration still produces an expensive, half-empty table.

This guide covers what a contact enrichment API returns field by field, why a person record behaves nothing like a company record, how your input key changes the outcome more than the vendor choice does, what the two billing models cost on a real list of 1,000 people, and the four routes into the data: API, integrations, an AI assistant, or no code at all.

## What a contact enrichment API is, and what it returns

A contact enrichment API is a service you call with a partial identifier for a person and that answers with a fuller record for that same person. Nothing about it is magic. It resolves your identifier to an individual, gathers what is known about that individual across the sources it maintains, and returns a structured object your code can store.

The response splits into three layers, and they don't behave the same way at all.

**Identity attributes** are the stable ones: first name, last name, the canonical profile URL. They change almost never, and a good service returns them at a very high rate because they are what the match itself is built on.

**Professional attributes** are the useful ones: job title, seniority, function, company, time in role. These are the fields your segmentation and your routing rules depend on, and they are also the ones that quietly rot. People change jobs. A record enriched fourteen months ago isn't wrong because the vendor was bad, it's wrong because the person moved.

**Contact points** are the expensive ones: professional email, direct phone. They are expensive because they aren't attributes sitting in a profile waiting to be read. They are found, and finding them either succeeds or doesn't. This is why they are almost always priced separately from the rest of the record, and why treating them as just two more fields in the response is the most common budgeting mistake of the whole category.

Understanding that split changes how you design the integration. The first two layers are a lookup. The third is a search with an outcome. If you haven't read how the request path is built underneath, the [architecture of an enrichment API](https://derrick-app.com/data-enrichment-api/architecture) covers the request flow, caching and response shape in detail.

## Person records versus company records: two different entities

Teams routinely bundle contact enrichment and company enrichment into one ticket. They aren't one problem. They differ on the identifier, on the stability of the data, and on the shape of the failure.

|  | Contact enrichment | Company enrichment |
| --- | --- | --- |
| Entity | An individual person | An organization |
| Natural key | Email, profile URL, or name plus company | Domain name |
| Key quality | Ambiguous, several people share a name | Near unique, one domain, one company |
| Decay driver | Job changes, which never stop | Funding, headcount, acquisitions |
| Typical failure | Wrong person returned confidently | Parent versus subsidiary confusion |
| Cost profile | Contact points priced per result | Flat per record |

The row that matters most is key quality. A company has a domain, and a domain resolves to exactly one company. A person has a name, and names aren't unique. Three people named David Miller work in sales at companies with similar names, and only one of them is yours. That single asymmetry explains why contact enrichment carries a real risk that company enrichment doesn't: **a confident wrong match**. A company API that fails usually returns nothing. A contact API that fails can return somebody, and somebody is far more expensive than nobody, because nothing downstream will flag it.

Practical consequence: never treat the two as interchangeable in your pipeline. Enrich the company from the domain, enrich the person from a person-level key, and keep the two calls and their confidence signals separate.

## The input key decides your results, more than the vendor does

Here is the finding that reorders most integration projects. The variable with the largest effect on your output isn't which service you call. It's which identifier you can supply for every row.

There are four realistic keys, and they aren't equivalent.

**A professional email address** is the strongest. It's unique by construction, it carries the company domain inside it, and resolving it is deterministic. If you already hold verified emails, you start from the easiest possible position.

**A profile URL** is nearly as strong. It points at exactly one individual with no ambiguity at all, which is why it's the preferred join key whenever a list comes out of a professional network. It's the key to prefer if you have to choose one to standardize on.

**Full name plus company domain** is workable and it's what most CRM exports actually give you. It's a probabilistic match rather than a deterministic one, so it's exactly here that confidence scores stop being decoration and start being the thing you branch on.

**Full name plus company name** is the weak one, and it's unfortunately the most common. Company names are messy in a way domains never are: legal suffixes, trading names, translations, spelling drift. Resolving the company correctly becomes a prerequisite step before you can even attempt the person, and every error there propagates.

The operational conclusion is blunt: **upgrade your key before you shop for a vendor.** Turning a list of names plus company names into a list of names plus domains, then into profile URLs, will do more for your fill rate than switching services will. Teams routinely run a vendor bake-off to chase a few points of coverage while feeding both candidates their weakest possible key.

## Match rate: the number everyone quotes and nobody defines

Every vendor publishes a coverage number. Almost none of them publish the denominator, and the denominator is the entire question.

Consider three ways to compute a match rate on the same 1,000 rows, with the same underlying data.

| Denominator used | What it counts | Reported figure |
| --- | --- | --- |
| Rows you submitted | Every row, including the unusable ones | The honest one, and the lowest |
| Rows that resolved to a person | Excludes rows that never matched at all | Noticeably higher |
| Rows in the vendor's own sample | A curated benchmark list | The one on the website |

All three can be described as a match rate without anybody lying. This is why comparing two published percentages is close to meaningless, and why the only number worth trusting is the one you measure yourself.

The test is cheap and it takes an afternoon. Take 200 rows from your real list, not a clean sample, with all the messy ones left in. Run them. Then compute the only metric that matters to your business: **rows that came back with the specific field your workflow needs, divided by rows you submitted.** If your sequence cannot send without a verified email, then rows with a verified email over 200 is your match rate. Every other framing is marketing.

Run that test on your own data and you will usually find the real figure sits well below the published one. That's not a scandal, it's what happens when a curated benchmark meets a CRM export.

## Partial matches and what to do with a half-filled row

The binary mental model, either the row enriches or it doesn't, survives about a day in production. What you actually get back is a spectrum, and your code needs a branch for each band.

**Full match, high confidence.** Write it. This is the easy case and it is the majority of a well-keyed list.

**Full match, low confidence.** The dangerous band. The service found somebody plausible and is telling you it's not certain. Writing this straight into a CRM is how a competitor's employee ends up in your nurture sequence. Route it to a review queue, or discard it, but don't let it through silently because the fields happen to be populated.

**Partial match.** Identity and professional attributes came back, contact points did not. This is extremely common and it's not a failure. The record is genuinely useful for segmentation and account mapping, it just isn't sendable yet. Store it, mark it, and run a dedicated contact point lookup on it separately.

**No match.** Don't retry the same call with the same key and hope. Retrying an identical request against an unchanged dataset returns an identical answer, and on per-attempt pricing you pay for the privilege. Either upgrade the key and retry, or park the row.

Two rules save more money than any other tuning. **Deduplicate before you enrich, never after.** A list assembled from several sources always carries overlap, and paying twice to enrich the same person is pure waste. **Set a freshness window.** Re-enriching a record touched last week is spend with no information gain; a quarterly refresh on active records catches the job changes that actually matter. If you are calling in volume, [rate limits and quota management](https://derrick-app.com/data-enrichment-api/rate-limits) covers how to pace those batches without hitting a wall.

## What a contact enrichment API costs: per attempt or per result

This is the single most consequential line in any enrichment contract, and it's usually buried. Two billing models exist, and on a real list they don't produce remotely similar invoices.

**Per attempt** means the call is billed whether or not it returns anything. Predictable to forecast, and it means you fund every failure.

**Per result** means you are billed only when the service actually returns the thing you asked for. The failures cost nothing.

Derrick prices the layers separately, and along exactly that line. Profile-level enrichment is billed per row submitted, because a lookup either reads the profile or the row was not usable. Contact points are billed per result found, because finding them is a search with an outcome.

| Operation | Cost | Billed | Plans |
| --- | --- | --- | --- |
| [Enrich Leads](https://derrick-app.com/features/enrich-leads) | 1 credit per profile | Per row submitted | Free and paid |
| [Email Finder](https://derrick-app.com/features/email-finder) | 5 credits per email | Per result found | Paid, from 9 euros per month |
| [Phone Finder](https://derrick-app.com/features/phone-finder) | 150 credits per phone | Per result found | Paid, from 9 euros per month |
| [Email Verification](https://derrick-app.com/features/email-verification) | 1 credit per email | Per result found | Paid, from 9 euros per month |
| Find Duplicates | No credit cost | Unlimited | Free and paid |

Put a real list against those numbers. Take 1,000 contacts you want emails for, and assume 600 of them resolve. Under per-result billing you are charged for the 600 that worked: 3,000 credits. Under per-attempt billing you are charged for all 1,000 attempts at the same unit price: 5,000 credits. Same data, same outcome, **67 percent more spend**, and the gap widens as your list gets harder, which is precisely when budgets are already under pressure.

That's also why the model deserves more scrutiny than the headline unit price. A lower price per call, billed on every attempt, is frequently the more expensive contract on a messy list. The free plan includes 100 credits per month, which is enough to run this arithmetic on your own data before committing to anything, and paid plans start at 9 euros per month.

## Calling a contact enrichment API from your stack: API, integrations, MCP

Once the data questions are settled, the delivery question is just which surface fits the system you already run. There are three, and they suit different jobs.

**The API.** Derrick exposes its enrichment endpoints from the Standard plan at 20 euros per month. Your code keeps orchestration, retries and storage, and calls a documented, versioned interface for the enrichment itself. This is the right route when enrichment has to happen inside an application you own, on your own trigger and your own schedule. Worth reading alongside it: [API authentication and encryption](https://derrick-app.com/data-enrichment-api/security), because a contact enrichment integration handles personal data and the key management is not an afterthought.

**Integrations.** With 3000+ integrations through Zapier, Make and N8N, enrichment becomes a step in a workflow rather than a service you host. A new CRM record, a form submission or a scheduled job triggers the call, and nothing needs to be deployed. For event-driven pipelines specifically, [triggering enrichment from webhooks](https://derrick-app.com/data-enrichment-api/webhooks) walks through the full pattern.

**MCP.** [Derrick MCP](https://derrick-app.com/mcp) puts the same data behind an AI assistant. From Claude Desktop, ChatGPT or any MCP compatible client, an agent asks for the enrichment it needs and receives a structured answer in the conversation, with no integration to write at all. It is available from the Standard plan at 20 euros per month. For agentic workflows this is a materially better contract than wrapping an HTTP client in a tool definition and maintaining it yourself.

## The no-code route: enrichment inside Google Sheets

A large share of the teams that scope an API integration don't need one. The requirement, stated honestly, is often that a list of 3,000 people needs job titles and emails before a campaign goes out next week. That is a spreadsheet problem wearing an engineering costume.

Derrick runs as a sidebar inside Google Sheets. You point it at a column, and it writes the enriched fields back into the rows next to it. Same data, same per result billing on contact points, no repository and no deployment. For a recurring prospecting list this isn't the lesser option, it's the correct one: there's nothing to maintain, and the same sidebar handles fifty rows or ten thousand without a second architecture.

The sequence that works, in this order. Deduplicate the file first, at no credit cost, so you never pay twice for the same person. Enrich the profiles to get titles, seniority and company. Then run contact point lookups only on the rows that passed your fit criteria, because that is where the credits actually go. Verify the emails before sending, so a stale address does not cost you domain reputation.

Doing it in that order on 3,000 rows takes an afternoon. The same job scoped as an integration takes a sprint and still needs someone to own it afterwards. That comparison, not a feature grid, is what usually settles the decision, and the [complete developer guide to enrichment APIs](https://derrick-app.com/data-enrichment-api) covers where each route fits.

## Contact enrichment API checklist before you integrate

Nine questions. Answer them before you sign anything, and the integration stops being a gamble.

**1. What key can I supply for every row?** Not for the best rows. For every row. This sets your ceiling before any vendor is involved.

**2. Can I upgrade that key first?** Names plus company names into names plus domains is usually the highest return work available.

**3. Which single field does my workflow actually require?** Measure coverage on that field alone, not on the record as a whole.

**4. What is the match rate on my own 200 rows?** Measured with rows submitted as the denominator, on real data, not a sample.

**5. Am I billed per attempt or per result?** On a 1,000 row list at 60 percent resolution, that choice moves the invoice by two thirds.

**6. What happens on a low confidence match?** If the answer is that it gets written anyway, fix that before launch, not after.

**7. Do I deduplicate before enriching?** Before. Always before.

**8. How often do I refresh?** Quarterly on active records catches job changes without paying for nothing.

**9. Do I need an integration at all?** Ask it honestly. A recurring list in a spreadsheet rarely does.

Answer those and the rest is implementation detail. The failure mode of this category is not a bad endpoint, it's a good endpoint fed a weak key, measured with the vendor's denominator, and billed on every attempt. None of those three is a technical problem, which is exactly why the technical review never catches them.

## Use Derrick in Claude (MCP) or via API

Derrick isn't only a Google Sheets add-on. The same B2B data enrichment runs as an MCP server (use it directly inside Claude and other AI agents) and as a REST API:

- **Claude / AI agents (MCP)**: connect the Derrick MCP server, then enrich from chat. Setup: /mcp
- **REST API**: call the same enrichment endpoints from your own stack (Standard plan and up). Docs: https://app1.derrick-app.com/api/v1/docs/

## FAQ

### What is a contact enrichment API?
It is a service you call with a partial identifier for a person, such as an email address, a profile URL or a name plus a company domain, and that returns a fuller record for that same person. The response comes in three layers: identity attributes like first and last name, professional attributes like job title and seniority, and contact points like a professional email or a direct phone. The first two are a lookup. The third is a search that either succeeds or does not, which is why it is almost always priced separately.

### What is the difference between contact enrichment and company enrichment?
The entity and the key. A company is identified by its domain, which is near unique, so a failed company lookup usually returns nothing. A person is identified by a name, which is not unique, so a failed contact lookup can return the wrong person with high apparent confidence. That confident wrong match is the specific risk of contact enrichment, and nothing downstream will flag it. Keep the two calls separate in your pipeline and branch on the confidence signal for the person-level one.

### Which input key gives the best match rate?
In order: a professional email address, then a profile URL, then a full name plus company domain, then a full name plus company name. The first two are deterministic because they point at exactly one individual. The last one is the weakest and the most common, because company names carry legal suffixes, trading names and spelling drift that domains never do. Upgrading your key will usually do more for your fill rate than switching vendors.

### What is a good match rate for a contact enrichment API?
There is no comparable published figure, because vendors do not use the same denominator. The same data can be reported against rows you submitted, against rows that resolved to a person, or against a curated benchmark list, and all three can honestly be called a match rate. Measure it yourself: run 200 rows from your real list, then divide the rows that came back with the specific field your workflow needs by the rows you submitted. That is the only number that predicts your results.

### How much does contact enrichment cost per contact?
With Derrick, profile enrichment costs 1 credit per profile through Enrich Leads, available from the free plan, and is billed per row submitted. Contact points are billed per result found: Email Finder is 5 credits per email found and Phone Finder is 150 credits per phone found, both on paid plans from 9 euros per month. Email Verification is 1 credit per email. Find Duplicates has no credit cost, and running it before enrichment stops you paying twice for the same person.

### Should I be billed per attempt or per result?
Per result, whenever the operation is a search rather than a lookup. Take 1,000 contacts you want emails for, where 600 resolve. At 5 credits each, per result billing charges the 600 that worked, so 3,000 credits. Per attempt billing charges all 1,000 attempts, so 5,000 credits, which is 67 percent more for identical data. The gap widens as your list gets harder, so a lower headline price billed on every attempt is often the more expensive contract.

### Do I need an API to enrich contacts?
Often not. If the requirement is that a recurring list needs job titles and emails before a campaign goes out, that is a spreadsheet job. Derrick runs as a sidebar inside Google Sheets, writes enriched fields back into the rows, and handles fifty rows or ten thousand with nothing to deploy or maintain. An API makes sense when enrichment has to happen inside an application you own, on your own trigger, which Derrick supports from the Standard plan at 20 euros per month.

### Can an AI agent call a contact enrichment API directly?
Yes, and it does not need a custom integration to do it. Derrick MCP exposes the enrichment layer to Claude Desktop, ChatGPT or any MCP compatible client, so an agent asks for the data it needs and receives a structured answer in the conversation. It is available from the Standard plan at 20 euros per month. For an agentic workflow that is a more durable contract than wrapping an HTTP client in a tool definition and maintaining it yourself.

## Related

- [The 2026 State of Data Enrichment APIs: Market, Architecture and Reliability Benchmark](https://derrick-app.com/data-enrichment-api/data-enrichment-api-report-2026)
- [Data Enrichment API: Architecture and How It Works](https://derrick-app.com/data-enrichment-api/architecture)
- [Webhooks and Data Enrichment: How to Trigger Enrichment from Events](https://derrick-app.com/data-enrichment-api/webhooks)
- [API Rate Limits and Quota Management: Everything You Need to Know](https://derrick-app.com/data-enrichment-api/rate-limits)
- [API Security: Authentication & Encryption - Full Guide 2026](https://derrick-app.com/data-enrichment-api/security)
- [SLA & Uptime Guarantees: What Every Sales Team Needs to Know Before Signing](https://derrick-app.com/data-enrichment-api/sla)
- [Custom Integrations: Build vs Buy - How to Make the Right Call](https://derrick-app.com/data-enrichment-api/build-vs-buy)
- [Top 7 Best Screenshot APIs to Automate Web Page Captures in 2026](https://derrick-app.com/data-enrichment-api/screenshot-api)
- [Data Enrichment API Pricing: How the Models and Costs Really Work](https://derrick-app.com/data-enrichment-api/api-pricing)