---
title: "Company Data API: Fields, Inputs and Real Costs"
description: "A company data API returns different fields depending on the key you send. Map input to field, measure real coverage, then compute cost per usable row."
canonical: "https://derrick-app.com/data-enrichment-api/company-data-api"
category: "Data Enrichment API"
updated: "2026-08-13"
---

# Company Data API: The Input Decides the Field, and the Field Decides the Price

> A company data API takes one identifier for an organization, a domain, a company name, a LinkedIn URL or a registration number, and returns a structured record: identity, firmographics, relationships and signals. The key you can supply for every row constrains the result far more than the provider you pick, because each key can only resolve part of the schema. A domain addresses technology and firmographics, a LinkedIn URL addresses people and hiring, and only a SIREN or SIRET returns legally filed directors and registered addresses. Billing decides the rest: per attempt charges every call, per result charges only what resolves. On 1,000 companies at 70 percent resolution, that one clause moves the invoice by 30 percent.

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

---

A company data API is a service you call with one identifier for an organization, and that answers with a structured record: legal name, domain, industry, headcount, location, and whatever else the provider maintains. The endpoint is the easy part. What decides whether your integration produces a usable table is which identifier you can supply for every row, and which fields that identifier is actually able to resolve.

Most integration reviews never ask that question. They compare response schemas, latency and price per call, then ship. Three weeks later the table is 40 percent empty and nobody can say why, because the gap was never in the code.

This guide covers what a company data API returns layer by layer, the three input keys and what each one can resolve, the field by field reality behind a single coverage percentage, the registry data that US first providers usually skip, the two billing models and what they cost on a real list, what breaks in production, and when an API is simply the wrong surface for the job.

## What a company data API returns, layer by layer

The response of a company data API is not one flat object with equal confidence across every key. It comes in four layers, and they behave very differently once you put them under load.

**Identity attributes.** Legal name, trading name, domain, country, registration number. These are close to facts. They change rarely, they are usually verifiable against a public source, and a mismatch here is a resolution bug rather than a data quality issue.

**Firmographic attributes.** Industry, headcount band, revenue band, founding year, headquarters city. These are estimates presented as values. Headcount in particular is a snapshot of whatever the provider last observed, and two providers can legitimately disagree by a factor of two on the same organization because they count contractors, subsidiaries and inactive profiles differently.

**Relationship attributes.** Parent company, subsidiaries, similar companies, the people who work there. These are derived, which means they carry the error rate of whatever built them plus the error rate of the underlying records.

**Signal attributes.** Hiring activity, funding, technology in use, recent news. These are the only layer where freshness matters more than accuracy, because a correct signal delivered six weeks late has no commercial value at all.

Treat the four layers as four separate decisions. Storing them in one table with one confidence score is how a firmographic estimate ends up being used as if it were a registration number.

## The three input keys, and what each one can resolve

Every company lookup starts from one of three keys. The choice is made for you by whatever your CRM already stores, and it constrains the result far more than the provider you pick.

**The domain.** The strongest key by a wide margin, because a domain is close to unique and it is machine readable. One domain, one organization, in almost every case. The exceptions are real but bounded: country subdomains, holding structures that operate several brands under one domain, and agencies that host client sites. If you can supply a domain for every row, do that and stop optimizing the rest.

**The company name.** The weakest key, and the one most lists actually contain. Company names are not unique, they are entered by humans, and they collide across countries. A name lookup that returns something with high confidence is the specific failure mode of this category: you get a plausible record for a different organization, and nothing downstream will flag it. If name is all you have, resolve it to a domain or a registration number first, then enrich from that resolved key.

**The LinkedIn company URL.** Deterministic like a domain, and it unlocks a different slice of data: the page description, the headcount the company publishes about itself, the industry it declares, and the people attached to it. It is the right key when your list came from social prospecting rather than from a CRM export.

A fourth key exists in Europe and gets forgotten: the registration number. In France that is the SIREN or the SIRET, and it is the only key in this list that is legally authoritative rather than commercially observed. More on that in part 05.

## Which field comes from which input

This is the table that should exist in every integration document and almost never does. It maps what you can send against what you can realistically expect back.

| Field you want | Domain | Company name | LinkedIn URL | SIREN / SIRET |
| --- | --- | --- | --- | --- |
| Legal name | Reliable | Input, not output | Reliable | Authoritative |
| Domain | Input, not output | Resolvable, verify it | Usually present | Often missing |
| Industry | Reliable | Weak, name collisions | Self declared | Authoritative code |
| Headcount | Estimate | Estimate | Self declared band | Declared band |
| Registered address | Sometimes | Weak | City level | Authoritative |
| Directors and officers | Rarely | Rarely | Not exposed | Authoritative |
| People who work there | Indirect | Indirect | Strong | Not available |
| Technology in use | Strong | Not addressable | Not addressable | Not addressable |
| Hiring activity | Indirect | Indirect | Strong | Not available |

Read one row and one decision falls out. If your pipeline needs directors and registered addresses for French accounts, no amount of domain enrichment will get you there, and no vendor comparison will tell you that. You need the registry key. Conversely, if you need the technology a prospect runs, only the domain addresses it, because that answer is produced by inspecting the site rather than by looking anything up.

Derrick exposes these as separate operations rather than one opaque call, which is what makes the mapping visible: [Enrich Companies](https://derrick-app.com/features/enrich-companies) at 1 credit per company from a LinkedIn page, [Search Companies](https://derrick-app.com/features/search-companies) at 1 credit per company to resolve a name into its LinkedIn URL, [Website Technologies](https://derrick-app.com/features/website-technologies) at 2 credits per website from a domain, and [Company Hiring Signal](https://derrick-app.com/features/company-hiring-signal) at 1 credit per company. The first two and the hiring signal are available on the free plan; Website Technologies is a premium feature. So you can measure your own resolution rate on most of the mapping before you write a line of integration code.

## Coverage is not one number, read it field by field

A provider that advertises 95 percent coverage is telling you about its easiest field, on its own denominator. Both halves of that sentence matter.

The denominator first. Coverage measured on rows submitted is the only figure that maps to your invoice and your table. Coverage measured on rows matched excludes every row the provider could not resolve at all, which is precisely the population you are worried about. The two numbers can differ by thirty points on the same run and both are technically true.

Then the field. Legal name and domain resolve at rates close to the match rate itself. Headcount and industry usually follow within a few points, because they come from the same record. Registered address, directors, and anything requiring a legal source drop hard outside the provider's home market. Technology and hiring signals are not comparable to any of it, because they are searches rather than lookups: they succeed or they do not, and a miss is not necessarily an error.

The practical test takes an afternoon. Take 200 real rows from the list you actually intend to enrich, not a curated sample. Run them. Then count, per field, how many are populated, how many are populated and correct on a spot check of twenty, and how many you were billed for. That gives you three numbers per field, and those numbers are the only ones that should appear in the integration decision. Our page on [coverage rate versus accuracy rate](https://derrick-app.com/data-quality-management/coverage-vs-accuracy) works through the arithmetic in more detail.

## The registry layer most company data APIs skip

Commercial company data is observed. Registry company data is declared to a state and legally binding. They are not competing sources, they answer different questions, and confusing them is expensive.

In France the registry key is the SIREN, nine digits identifying the legal entity, and the SIRET, fourteen digits identifying one establishment of that entity. Attached to them you get the legal name exactly as filed, the registered address, the incorporation date, the legal form, the declared headcount band, the directors, and the NAF activity code. None of it is an estimate. All of it is what the company itself declared, which is a different kind of truth from what a crawler inferred.

This matters in three concrete situations. Contract and billing workflows need the legal name and the registered address, not the trading name and the office you found on a website. Compliance and vendor onboarding need the registration number as the join key, because it is the one identifier that survives a rebrand. And territory or segment definition in France works far better on the NAF code than on a provider's industry taxonomy, because the NAF code is what the company filed rather than what a classifier guessed.

Derrick covers this layer directly with [SIRET/SIREN/Name Enrichment](https://derrick-app.com/features/siret-siren-enrichment), at 1 credit per company, available on the free plan: send a SIRET, a SIREN or a company name and get identity, activity, directors and legal data back with a confidence score. The same registry is addressable in the other direction with [Import Companies by NAF Code](https://derrick-app.com/features/import-companies-by-naf), which turns an activity code into the full list of matching French companies. If you build lists for the French market, that pair replaces a scraping project.

Two notes before you wire it in. Registry data tells you what the entity is, never who to talk to, so you still need a people layer on top. And a registry record can be current and useless at the same time: a company that filed its headcount band two years ago is legally in order and commercially stale.

## What a company data API costs, per attempt or per result

Two billing models exist and the difference between them is not a detail. Per attempt charges every call, whether or not anything comes back. Per result charges only what resolves. On a list where a third of the rows will never resolve, that single line in the contract moves the invoice by a third.

Work it through on 1,000 companies with a 70 percent resolution rate, at 1 credit per company. Per attempt you pay 1,000 credits and receive 700 usable rows, so your cost per usable row is roughly 1.43 credits. Per result you pay 700 credits for the same 700 rows, at 1 credit each. Same data, same provider, 30 percent difference.

The number that should drive the decision is cost per usable row, never price per call. A cheap call with a low resolution rate loses to an expensive call with a high one, and the published price per call hides that completely.

Derrick's own credit grid runs from a free plan at 100 credits per month at no cost, then MINI at €9, STANDARD at €20, PLUS at €47.5, PRO at €175 and SCALE at €320 per month. API and MCP access open from a paid plan; the current unlock tier is on the pricing page, where the floor works out at €0.0016 per credit. Unused credits roll over. The reason we publish the whole grid rather than a single headline price is that cost per usable row only becomes computable once you can see both the credit price and the per operation cost. The full teardown lives on our [data enrichment API pricing](https://derrick-app.com/data-enrichment-api/api-pricing) page.

## What breaks in production, and what to build for it

Company enrichment integrations rarely fail on the happy path. They fail on the four things nobody tested.

**Bursts.** A nightly job that enriches a whole CRM segment will hit a per minute ceiling that your test of fifty rows never touched. Build the queue and the backoff before launch, not after the first failed run. The mechanics are in our guide on [API rate limits and quota management](https://derrick-app.com/data-enrichment-api/rate-limits).

**Retries that double bill.** A timeout is not a failure, it is an unknown outcome. Retrying it blindly on a per attempt contract charges you twice for one answer. Make the call idempotent on your side by keying on the input identifier and caching the outcome, including the empty ones.

**Empty results treated as errors.** A company that genuinely has no published headcount is not a 500. If your pipeline retries every empty field you will pay for the same nothing, repeatedly. Store the null and the timestamp, and refresh on a schedule instead.

**Silent overwrites.** The most expensive failure in this category is an enrichment run that overwrites a human verified field with a machine estimate. Write to staging columns, diff, then promote. Our page on [data enrichment API architecture](https://derrick-app.com/data-enrichment-api/architecture) covers the queue, cache and promotion pattern end to end, and [webhooks and data enrichment](https://derrick-app.com/data-enrichment-api/webhooks) covers the event driven version.

## When an API is the wrong surface

An API is the right answer for a recurring, automated, system to system flow: a CRM that enriches on record creation, a nightly refresh, a product that needs company data at signup. If that describes you, integrate.

It is the wrong answer more often than vendors admit. If the real job is a list that a human curates and hands to a sales team, an API adds an engineering dependency to a task that never needed one. Derrick runs from a sidebar inside Google Sheets, so the same enrichment happens on a column with no code and no deployment, and the person who owns the list owns the run.

And if the job is a question rather than a list, neither surface fits. Ask it in a chat instead: [Derrick MCP](https://derrick-app.com/mcp), included from a paid plan, plugs the same enrichment into Claude, ChatGPT and any MCP compatible client, so the lookup happens where you are already thinking. Our [build versus buy](https://derrick-app.com/data-enrichment-api/build-vs-buy) guide runs the same decision for the integration itself.

Pick the surface from the use case, not from the org chart. A list to enrich goes to Sheets. A question in a chat goes to MCP. A recurring automated workflow goes to the API. Most teams need two of the three, and choosing one of them for everything is what produces either a shadow spreadsheet or an unused integration.

## A company data API checklist you can run this week

Nine questions, in order. Answer them and the rest is implementation detail.

**1. Which key can I supply for 100 percent of rows?** Domain, name, LinkedIn URL or registration number. That answer constrains everything downstream.

**2. If the answer is name, what resolves it first?** Resolve name to domain or to a registration number as a separate, auditable step. Never enrich straight from a name and trust the result.

**3. Which two fields does the workflow actually need?** Not the full schema. Two. Measure coverage on those, and ignore the rest of the response.

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

**5. Do I need registry data?** If any downstream step is contractual, legal or French market segmentation, yes, and no commercial source substitutes for it.

**6. Am I billed per attempt or per result?** Then compute cost per usable row, not price per call.

**7. What happens to a low confidence match?** If the answer is that it gets written to the CRM anyway, fix that before launch.

**8. How often do I refresh, and which layer?** Identity almost never, firmographics quarterly, signals weekly or they are worthless.

**9. Do I need an integration at all?** Ask it honestly. A monthly list that one person owns rarely does.

The failure mode of this category is not a bad endpoint. It is a good endpoint fed a weak key, measured on 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 (PLUS plan and up). Docs: https://app1.derrick-app.com/api/v1/docs/

## FAQ

### What is a company data API?
It is a service you call with one identifier for an organization, such as a domain, a company name, a LinkedIn company URL or a registration number, and that returns a structured record for that organization. The response arrives in four layers that behave differently: identity attributes which are close to facts, firmographic attributes which are estimates presented as values, relationship attributes which are derived, and signal attributes where freshness matters more than accuracy. Treating those four as one object with a single confidence score is the most common design mistake in the category.

### Which input key gives the best results?
The domain, by a wide margin, because it is close to unique and machine readable. The LinkedIn company URL is equally deterministic and unlocks a different slice: people, self declared headcount and hiring activity. The company name is the weakest key and the one most lists actually contain, because names are not unique and collide across countries. If name is all you have, resolve it to a domain or a registration number as a separate step, then enrich from the resolved key.

### What is the difference between a company data API and a contact enrichment API?
The entity and the key. A company is identified by a domain, which is near unique, so a failed lookup usually returns nothing at all. A person is identified by a name, which is ambiguous, so a failed lookup can return the wrong person with high apparent confidence. That is why company enrichment fails loudly and contact enrichment fails silently, and why the two calls should stay separate in your pipeline.

### Why does a published coverage rate never match what I get?
Two reasons, and both are about measurement rather than data. The denominator: coverage measured on rows matched excludes every row that could not be resolved, which is exactly the population you care about, while coverage measured on rows submitted maps to your invoice. And the field: a single headline percentage describes the easiest field, usually legal name or domain, not the registered address or the directors you actually needed.

### Can a company data API return French registry data like SIREN, SIRET and NAF codes?
Some can, most do not, because commercially observed data and state filed data are different sources. The registry layer returns the legal name as filed, the registered address, the incorporation date, the legal form, the directors and the NAF activity code, none of which is an estimate. Derrick covers it with SIRET/SIREN/Name Enrichment at 1 credit per company on the free plan, and in the other direction with Import Companies by NAF Code, which turns an activity code into the matching list of French companies.

### How much does a company data API cost?
The published price per call is the wrong number. What matters is cost per usable row, which combines the price with your actual resolution rate and the billing model. On 1,000 companies at 70 percent resolution and 1 credit per company, per attempt billing costs 1,000 credits for 700 usable rows, roughly 1.43 credits each, while per result billing costs 700. Derrick's grid starts at a free plan with 100 credits per month, then MINI at 9 euros, STANDARD at 20 euros, PLUS at 47.5 euros, PRO at 175 euros and SCALE at 320 euros per month, with API and MCP access opening from a paid plan.

### Do I need an API at all?
Only if the flow is recurring, automated and system to system, such as a CRM enriching on record creation or a nightly refresh. If the real job is a list a human curates, an API adds an engineering dependency that the task never needed, and a Google Sheets sidebar does the same enrichment on a column with no code. If the job is a one off question rather than a list, neither fits and an MCP client is the right surface.

## 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)
- [Screenshot API: Top 7 Tools 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)
- [Contact Enrichment API: What You Send, What You Get Back, What You Pay](https://derrick-app.com/data-enrichment-api/contact-enrichment-api)