How to Integrate Company Data Into a CRM Using an API

To integrate company data into a CRM using an API, normalise each account’s domain, call an enrichment endpoint once per unique domain, map the returned fields to CRM properties through explicit rules, and write only to fields the API owns. Add caching, a miss policy and an audit trail.

The architecture in one picture

Keep the enrichment logic outside the CRM, in a small service or scheduled job. Its flow:

1. Trigger. A new account is created, a signup arrives, or a nightly job selects stale records.
2. Normalise. Extract and clean the domain; skip personal mail domains.
3. Cache check. If you looked up this domain recently, reuse the result.
4. Lookup. Call the API; record found or not-found.
5. Map. Translate response fields to CRM properties.
6. Write. Update by rules; stamp last-enriched date and source.
7. Log. Store the raw response or a hash for audit and debugging.

The BusinessMCP Company Data API fits steps 4 to 5 for firmographics: lookup, bulk (up to 100 domains per call, per its page), search, website status and email pattern. Its guide on adding company enrichment walks through the REST and MCP routes.

Field mapping

Decide the mapping before you write code:

API concept	CRM property idea	Rule
Company name	Account name	Fill if empty; never overwrite
Industry	Industry (picklist)	Map labels to your picklist; unmapped goes to “Other” for review
Size band	Employee range	Store as a band, not a number
Location	Country, city	Fill empty; compare with billing address
Phone	Main phone	Fill empty only
LinkedIn URL	Company LinkedIn	Fill empty
Website status	Website active (dated)	Overwrite; it is a measurement
Enriched at	Last enriched date	Always overwrite

Key takeaway: write an ownership rule for every field. Enrichment that silently overwrites rep-entered data teaches the sales team to distrust the CRM.

Real time versus batch

Real time suits new records: when a form submission arrives with a work email, resolve the domain immediately so routing and scoring have the data. See work email to company lookup.

Batch suits backfills and refreshes. Select accounts that are missing fields or have an old last-enriched date, deduplicate domains, and send them in bulk calls. Keep batches inside your balance and rate limits; the provider’s guide lists 60 requests a minute for bulk and per-unit tools. Details are in bulk company lookup.

Handling misses and errors

• Not found. Mark enrichment_status = unknown with a date and retry in weeks. Do not loop.
• Retryable errors. Retry with backoff and an idempotency key so you are not billed twice; the provider’s guide recommends sending one.
• Payment or limit errors. Treat 402 as an empty balance or spend limit and alert a human; the guide describes it that way.
• Bad input. A 400 means your normalisation missed something; fix the input, do not retry.

Deduplication and merging

Enriched data often reveals that two CRM accounts are the same company. Decide up front whether the enrichment job may flag duplicates (safe) or merge them (risky). Flagging with a review queue is the sensible default, since merging destroys history.

Governance

Record which vendor and endpoint filled each value, plus the date. If a regulator, customer or rep asks where something came from, you can answer. Also check your vendor’s terms on data origin and permitted use. The company endpoints described by BusinessMCP are company-level only, with no personal data, which simplifies privacy review compared with people data; still confirm with your own counsel.

Testing the integration

1. Run it on a sandbox copy of the CRM first.
2. Process 200 accounts and review a sample by hand.
3. Compare found rates by segment against your earlier test (see how to get company data through an API).
4. Check that no rep-owned field changed.
5. Set a spend cap before running the full backfill.

Cost control

Per-hit pricing makes the cost of a backfill predictable: at $0.02 per found lookup, an estimate is accounts times hit rate times price, with the usual caution that your hit rate decides the number. Our pricing article has the formula. Cache results so a re-run does not pay twice.

When to use a bundled enrichment instead

If your CRM already includes enrichment on your plan, it may write straight into records with no code. The trade-off is flexibility and API access, covered in our look at enrichment options. A custom integration earns its keep when you need control over rules, multiple CRMs or agent access.

Example: a nightly enrichment job

Here is a concrete outline you can adapt. Each night at 02:00 the job queries the CRM for accounts where domain is not empty and either last_enriched is null or older than 90 days, limiting to 5,000 rows. It cleans and deduplicates the domains, drops any with a fresh cache entry, and sends the rest to bulk lookup in batches of 100, as described in bulk company lookup. For each result it writes the fields allowed by the ownership table, sets enrichment_status to found or unknown, and stamps last_enriched. At the end it posts a summary to a channel: rows processed, found rate, spend, errors. If the found rate drops sharply versus the 7-day average, it alerts a human, since that can indicate a bad input change or an upstream problem.

Using website status as a CRM field

The provider’s lookup returns website status with a measured date, per its page. Mapping that to a CRM field lets you build lists such as “active accounts with a responding site”. See company website status for how to read and refresh it. For the exact response structure consult the API reference.

Permissions and security

Store the API key in a secrets manager, rotate it on a schedule, and give the integration its own CRM service user with the minimum write permissions. Log every write with a before and after value for enrichment-owned fields so you can roll back a bad run. Keep the raw API responses for a short, defined retention period for debugging, and delete them afterwards, since even company data can contain phone numbers you do not want lying around.

Testing for regressions

Keep a small fixture set of domains with known expected outputs: one found with all fields, one found partial, one not found, one brand platform domain. Run it in CI against a mock or a staging key. When the vendor changes a response shape, your tests fail before your CRM is polluted. This takes an hour to set up and saves days of cleanup. If you later change vendors, as discussed in Clearbit alternatives, the same fixtures help validate the new one.