Company Enrichment API: Pricing, Endpoints, and Integration

A GTM engineer opens a CRM export and finds 10,000 company records with missing employee ranges, stale domains, and no technology data. Sales wants the list ready for routing, marketing needs usable segments, and an AI workflow is about to personalize outreach from whatever fields it can find. The hard part isn't adding columns. It's deciding which company each record refers to, whether the returned values are trustworthy, and how to keep the data from going stale again.

A company enrichment API can turn an identifier such as a company domain or name into a structured company profile. In production, though, the endpoint is only one part of the system. Identity resolution, source routing, field-level quality, failure handling, and cost visibility determine whether the resulting data helps your workflows or creates new problems.

Table of Contents

• What a Company Enrichment API Does
  • Where company data gets used
  • What the API can't decide for you
• Core Endpoints and Returned Firmographics
  • Endpoint map
  • Map to your own schema
• How Enrichment Works Under the Hood
  • Routing, then reconciliation
  • Freshness and operational trade-offs
• Example Requests and Responses
  • Company lookup flow
  • Related request patterns
  • Failures are part of the API contract
• Rate Limits, Credits, and Pricing Models
  • Estimate using your own workflow
  • Rate limits and operational cost
• Integration Patterns for GTM Workflows
  • Real-time calls and scheduled refresh
  • Bulk jobs, webhooks, and agents
• Data Quality and Identity Resolution
  • Make field quality inspectable
  • Measure outcomes after the response
• Quick Reference and Evaluation Checklist
  • Evaluation checklist

What a Company Enrichment API Does

The engineer's export has a familiar shape: some records have a company name but no domain, others have a domain that redirects to a new brand, and plenty contain an employee count copied into the CRM long ago. A company enrichment API takes an identifier the team already has and attempts to return useful company-level context in a consistent structure. That context may include a legal or trading name, website, industry, size range, location, corporate status, and technology signals, depending on the endpoint and provider.

The distinction between a lookup and enrichment matters. A lookup might match a domain to a single stored company row. Enrichment is the larger job of resolving which entity the input represents, normalizing values from different systems, selecting or reconciling provider results, and returning a record that downstream software can use. If two firms share a name, a lookup may produce a plausible but incorrect match. A careful enrichment flow should treat that as an identity problem, not as permission to fill every empty field.

Where company data gets used

CRMs use firmographics to segment and route accounts. Sales automation can use company context to prioritize a task or personalize a sequence. Analytics platforms depend on consistent industry and size fields to make comparisons meaningful. AI agents may use the same attributes to decide what to research or which records to act on, so an incorrect value can travel farther than it would in a human-reviewed spreadsheet.

The broader challenge is global fragmentation. One commercial company-data provider describes coverage of more than 375 million businesses across over 190 countries, drawing from more than 1,200 official registry sources. That commercial dataset isn't a government census, but its scale illustrates why a globally usable API has to reconcile varied registration systems, legal names, address formats, industry classifications, and status fields (CompanyData's overview of its business coverage).

What the API can't decide for you

An API can return structured data. Your integration still has to decide when to enrich, which fields are allowed to overwrite existing values, and what to do when the entity match is uncertain. A common safe pattern is to preserve the original CRM value, store the enriched value separately, and apply explicit survivorship rules before updating a canonical account record.

The practical test: if you can't explain how a response becomes a CRM update, you're not evaluating enrichment yet. You're evaluating a data feed.

Core Endpoints and Returned Firmographics

Company-level enrichment and contact-level enrichment solve related but different problems. A company endpoint helps identify and describe an organization. People and contact endpoints help find or verify individuals associated with it. A GTM workflow often needs both, but keeping their schemas separate makes it easier to govern changes and avoid treating a person's attributes as company facts.

A domain is usually a useful company input because it gives the resolver a concrete identity clue. A company name can help, especially when paired with the domain, but names can be ambiguous across legal entities, brands, and subsidiaries. When an API supports stable company identifiers, use them for follow-up calls instead of repeatedly resolving a text name.

Endpoint map

Treat that table as a schema-planning guide, not a promise that every vendor returns every field. Employee counts, revenue bands, industry codes, and corporate status can be defined differently by providers. A field called “industry” may be a broad label in one response and a mapped classification code in another. Store the provider value and the normalized value distinctly if you need to audit or remap the data later.

Map to your own schema

Start by listing the fields your workflows consume. A sales-routing rule may need headquarters country and employee range, while account segmentation may depend on industry classification and parent-company identity. Avoid copying a provider's entire response into a CRM without deciding how each field will be interpreted.

For segmentation logic, define categories that match your own sales motion rather than assuming a vendor's industry labels map directly to your account tiers. The practical considerations behind that design are covered in this guide to firmographic segmentation.

People search and enrichment should usually write to contact records, with a reference back to the matched company identifier. That keeps company facts from being duplicated across every contact and gives your systems a clear way to update account-level data without rewriting person records.

How Enrichment Works Under the Hood

A company lookup can return a confident match while still relying on an outdated or incomplete source. Behind the endpoint, an enrichment service identifies the input, routes the request to data providers, and resolves their responses into a usable result. Coverage varies by provider, geography, and field, so routing choices shape what the API can return and how quickly it can return it.

Routing, then reconciliation

A waterfall checks providers in sequence. The service tries an eligible source, evaluates whether the match meets its rules, then moves to another provider if no usable match is found or a requested field is missing. Parallel routing queries multiple sources at once. It can reduce reliance on one slow provider, but it requires rules for resolving conflicting results and handling partial responses.

Provider redundancy helps when a source lacks local coverage, is temporarily unavailable, or has stale information. It does not guarantee accuracy. If providers disagree on a legal name or employee range, the service needs a field-level selection rule. A blanket “last response wins” merge makes outcomes dependent on timing rather than data quality.

Execution logs make routing behavior diagnosable. Check whether they record providers attempted, response status, match decisions, and the reason a value was selected. Those details help distinguish a coverage gap from a timeout or a conflict-resolution rule. How to store and audit returned values is covered under data quality below.

Freshness and operational trade-offs

Sequential routing can make fallback order easier to understand, while parallel calls can increase speed at the cost of more reconciliation work. Either approach also affects latency and provider usage. If the API charges per provider call, parallel routing may consume more credits than a waterfall that stops after a usable result.

Freshness remains separate from identity matching. A response can point to the correct company and still contain an outdated domain, location, or operating status. For production workflows, set refresh expectations according to how quickly each field changes, and use execution records to investigate stale or conflicting results.

Example Requests and Responses

An integration example is useful only if it distinguishes the documented interface from the shape of a sample payload. The request below uses RichAPI's company enrichment endpoint path, /api/v1/enrich_company. Treat the body and returned fields as illustrative; confirm the authentication method, required parameters, and exact response schema in the provider's current API documentation before implementing against them.

Company lookup flow

A domain-based request might conceptually submit an input such as company_domain: "example.com". A representative response structure could contain an entity identifier, a normalized company name, a domain, an industry value, an employee range, and metadata recording which fields were verified and when. Those names describe a useful contract, not a guarantee that a particular service returns those exact keys.

Before writing the response into a CRM, validate the match state and required fields. If the company is ambiguous, route it to a review queue or return a non-destructive status rather than creating a new account automatically.

Related request patterns

A people-enrichment request generally needs a person identifier or supported contact clue, then returns person attributes linked to a company. An email-finder request may use a person's name and company context; an email-verifier request evaluates an address already in hand. A bulk submission should return a job or item-level outcomes so the caller can distinguish completed records from not-found, ambiguous, and failed records.

In a real implementation, store your own request identifier alongside the provider's correlation identifier. That gives support staff a way to trace a CRM update back to the original call without relying on the company's name or a contact's email as the only audit key.

Failures are part of the API contract

An invalid domain is a deterministic input problem, so retrying the same request won't help. A timeout may be transient and can justify a controlled retry. A no-match result is different again: it can mean the record isn't covered, the identifier is insufficient, or the entity couldn't be resolved confidently. Don't turn these distinct outcomes into a generic empty response.

RFC 9457 defines a machine-readable HTTP error format using application/problem+json, with a problem type that identifies the class of error (RFC 9457). A client can use that structure to distinguish validation errors from provider timeouts or rate limits. Retry transient failures with backoff and jitter, honor Retry-After when supplied, and avoid retrying deterministic errors. For bulk jobs, inspect every item's outcome instead of treating the whole submission as successful because the top-level request returned successfully.

Rate Limits, Credits, and Pricing Models

Pricing becomes hard to compare when one provider charges per call, another charges credits by endpoint, and a third bundles API access with seats or a platform subscription. The first step is to identify the billable event. Does a request consume a credit when the API receives it, only when a record matches, or when a particular field is returned? What happens to a provider timeout, an ambiguous match, or a retry?

A fixed-credit-per-endpoint model can make usage easier to forecast if the charge doesn't change according to which provider fulfills the request. A credit pool shared across endpoints is convenient for mixed workflows, but it can also make a high-volume endpoint consume capacity intended for another team. Ask for the billing behavior of misses and failed calls in writing, then verify it against execution logs during a pilot.

Estimate using your own workflow

Use a simple model rather than a vendor's headline unit price:

Expected usage = submitted requests × billable share × credits per billable endpoint

The “billable share” depends on the provider's rules and your own match outcomes. Run a representative sample through the intended workflow, including records with weak identifiers and records that already have current data. This gives you a useful planning baseline without assuming that every row will match or that every failed lookup is free.

RichAPI's pricing details describe the available pricing structure. For any provider, also check for minimum commitments, overage behavior, expiration of unused credits, and charges for repeat enrichment. Don't assume that a successful HTTP response and a billable enrichment are the same thing.

Rate limits and operational cost

Rate limits constrain how quickly your integration can submit work, while concurrency limits may control how many requests can be active at once. Confirm both before designing a bulk job. If the API returns a rate-limit response, respect its retry guidance rather than increasing concurrency and creating a retry storm.

Execution logs should make the cost path inspectable: the requested endpoint, provider attempts, terminal outcome, and billing result. Without that record, a team may know its monthly spend but not which workflow or fallback path caused it. Keep retry behavior bounded, and make repeated requests idempotent where the API supports it.

Integration Patterns for GTM Workflows

Choose the integration pattern based on when a workflow needs the result and how much work it has to process. Real-time calls fit workflows that need company context before routing a new signup or evaluating an inbound lead. Scheduled jobs suit data maintenance, where teams can process accounts in batches and handle exceptions without holding up a user-facing action.

Real-time calls and scheduled refresh

For an inbound form, the application can submit a domain, wait for a company result, and apply routing rules if the match is usable. Keep the user-facing path resilient: enrichment should not make a form submission fail just because an upstream provider is temporarily unavailable. Queue the record for later enrichment if the response misses a practical latency or reliability requirement.

A scheduled refresh can read eligible accounts from a warehouse or CRM, submit them through a bulk endpoint, and apply results after validation. That makes it easier to control volume, compare changed values, and review uncertain matches. Enrichment is most useful as an ongoing maintenance process, not a one-time import; industry reporting cited by CUFinder describes B2B contact-data decay at approximately 2.1% per month, compounding to roughly 22% to 22.5% over a year (CUFinder's B2B data-quality statistics). The measure concerns contact data, so use it as context for data maintenance rather than as a precise forecast for every company field.

Bulk jobs, webhooks, and agents

For long-running work, submit a batch, persist its job identifier, and receive completion status through polling or an asynchronous webhook. Make webhook handling idempotent because a delivery can be repeated, and store item-level outcomes so a partial failure doesn't force you to rerun every successful record. When supported, use an idempotency key for job submission so a network retry doesn't create duplicate work.

REST is a straightforward fit for application services, warehouse jobs, and custom pipelines. An MCP server can expose enrichment actions to an AI agent, but the agent still needs clear tool constraints: which records it may enrich, which fields it may write, and how it should handle uncertain matches. No-code and orchestration tools such as Clay, TexAu, Bitscale, HubSpot, Zapier, and n8n can connect workflows, while Claude, Cursor, and Windsurf can work with agent or development integrations. Check the actual connector behavior before relying on it for retries or field-level updates.

For a broader view of where enrichment fits across revenue workflows, see this guide to sales data enrichment. Whatever the interface, use one canonical update path for CRM writes. Scattered automations that each enrich and overwrite the same account make conflicts difficult to trace.

Data Quality and Identity Resolution

A subsidiary can look like a strong enrichment match to its parent: the name is similar, the domain may be shared, and the employee count may be plausible. Yet if the subsidiary is the account your sales team works, replacing it with the parent changes the business relationship, not just the record's fields. Evaluate how an API handles that distinction before relying on its match results.

Model parent companies and subsidiaries as separate entities connected by an explicit relationship. For an acquisition, keep the acquired company's record and identifier, then represent its relationship to the buyer and whether it continues to operate as a separate account. When a domain changes hands, treat the old and new domains as evidence linking two records, not proof they represent the same account. A rebrand may preserve the entity; a sale of the domain alone does not.

Make field quality inspectable

Field-level acceptance rules should reflect how each value is used. Building on the preserve-and-compare pattern described earlier, set thresholds per field: a human-verified headquarters value can remain in place until a replacement passes a defined confidence bar, while a missing technology field may be filled from an approved source. Keep those rules explicit and testable.

Measure outcomes after the response

Track whether records resolve to the intended legal entity, required fields pass validation, duplicate creation changes, and downstream routing or reporting behaves correctly. A successful API response can still identify the wrong company or produce values unsuitable for the rule that consumes them.

A 2025 report cited by IVRIsTech found that 76% of respondents considered less than half of their CRM data accurate and complete, while 37% said poor data quality had caused revenue loss (IVRIsTech's CRM data-quality benchmarks). These are survey findings, not a forecast for any individual CRM. Measure enrichment by its effect on your own records, not by how many fields it fills.

A high-confidence response can still point to the wrong entity. Check the company relationship before accepting the match.

Quick Reference and Evaluation Checklist

A useful evaluation starts with a representative slice of your own account data, not a generic match-rate claim. Include easy domain matches, records with only company names, known subsidiaries, renamed companies, and records you already trust. Compare returned values against your verified records, and classify failures by cause. A single aggregate score hides whether the provider struggles with your geography, your company type, or your weakest identifiers.

Evaluation checklist

• Identity behavior: Confirm how the API handles ambiguous names, subsidiaries, parent companies, rebrands, and duplicate candidates. Ask whether it exposes a stable identifier and a match or confidence state.
• Field quality: Check field-level provenance, observed or refreshed timestamps, normalization details, and whether the original provider value is preserved.
• Freshness policy: Find out which fields are refreshed, what triggers a refresh, and how your integration can request a recheck. Treat freshness as an ongoing operating decision.
• Routing and resilience: Ask whether the service uses multiple providers, how it chooses among conflicting values, and what its response looks like when a provider times out.
• Cost visibility: Verify what consumes credits, how misses and retries are handled, and whether logs show provider attempts and billing outcomes.
• Integration fit: Test the REST or MCP interface, bulk submission, asynchronous completion, rate-limit handling, and item-level failure reporting with the systems you already use.
• Governance: Review source disclosures, permitted uses, retention, deletion and correction handling, suppression propagation, audit logs, and data-processing terms. A 2025 GDPR-oriented analysis discusses the need to document enriched data, purpose, legal basis, retention, subprocessors, and vendor data sources (GDPR-oriented guidance for B2B enrichment).

The decision shouldn't come down to match rate alone. A provider can match more records while giving you weaker evidence, less useful entity relationships, or less control over how values flow into downstream systems. Compare correct entity resolution, field-level evidence, operational resilience, and governance alongside coverage and cost.

For the next evaluation, choose a sample your team can manually verify, define the fields and outcomes that matter, and test the full path from request to CRM update. RichAPI provides a unified B2B enrichment interface through REST and MCP, with company endpoints, bulk processing, and provider-routing execution logs. If that fits your workflow, visit RichAPI to review the integration options and assess them against your requirements.