RevOps and SalesOps teams inherit CRM records that are just a company name and nothing else. Sales Nav needs a LinkedIn URL. Outbound tools need a domain. Dedup workflows need both. This guide shows how to turn a name-only row into a canonical {business_id, website, linkedin_profile} triple from inside Claude Code using two Explorium endpoints.
What This Playbook Solves
The specific problem: an account row shows up as Acme Corporation with no website, no LinkedIn URL, no domain, no country. Sales Nav can’t be pointed at it. The outbound tool can’t verify the mailing domain. Dedup rules can’t collapse it against an existing acme.com record. Every downstream system needs the same two identifiers — canonical website and LinkedIn company URL — but the CRM only has the name.
Why a two-call flow, not one
Explorium’s match endpoint is entity resolution: given fuzzy inputs, it decides which record you meant and returns a canonical business_id. It does not return the canonical website and LinkedIn URL as fielded strings. That is by design — match is fast and its only job is anchoring. To get the canonical fields for write-back, you enrich firmographics on the returned business_id. Two calls, one result: {business_id, website, linkedin_profile, name}.
Prerequisites
An Explorium API key in your Claude Code project. Put it in .env and never commit the file.
[code example — see docs.explorium.ai]
Every call sends the key in the api_key header, not Authorization: Bearer.
Step 1, Standardize the Input
Ask Claude Code to normalize your input file. For every row, keep the original CRM account ID, the raw name, and any partial identifiers you do have (a website even if malformed, a LinkedIn URL if present). Lowercasing names, trimming trailing , Inc. / Ltd., and normalizing domains (drop http(s):// and www.) raises match confidence 5-15% on messy CRM exports.
Step 2, Match to a Canonical business_id
Batch up to 50 businesses per call. Send whatever identifiers you have — name is enough on its own; adding website or LinkedIn URL sharply raises accuracy.
[code example — see docs.explorium.ai]
The response preserves input order. Each row in matched_businesses[] returns a business_id or null if the row could not be resolved. Rows with a business_id proceed to Step 3; rows with null go to unmatched.csv for manual review.
How the matcher decides
- Name plus website triggers smart fuzzy logic on the name using the website as an anchor. This is the highest-confidence combination and Explorium’s recommended input shape.
- Website alone is the fallback path. Domains are unique across organizations, so this is reliable when the name is missing or noisy.
- Name alone triggers fuzzy resolution without a domain anchor. It is the weakest input and returns the highest share of null matches. Route these to review before writing back.
- LinkedIn company URL is accepted as an additional identifier and can disambiguate similarly-named companies across markets.
Step 3, Enrich Firmographics to Return Canonical Website + LinkedIn
Pass the resolved business_id batch to the firmographics bulk enrich endpoint. This is the call that returns the canonical fields you write back to the CRM.
[code example — see docs.explorium.ai]
Fields returned that matter for this workflow
| Field | Type | Use |
|---|---|---|
business_id | string | Anchor for write-back to CRM |
name | string | Canonical company name; compare against CRM name for a dedup flag |
website | string (URI) | Canonical company website; primary output |
linkedin_profile | string (URI) | Canonical LinkedIn company page URL; primary output |
linkedin_industry_category | string | LinkedIn’s own industry classification; useful for routing and segmentation |
country_name | string | Optional cross-check against CRM country if present |
Step 4, Assemble the Triple and Split Output
Join the match response to the enrichment response on business_id, then join back to your original CRM row on crm_id. Produce two files: matched.csv with the canonical triple for write-back, and unmatched.csv with rows the match endpoint could not resolve.
[code example — see docs.explorium.ai]
Step 5, Apply Write-Back Rules
The canonical triple looks tempting to overwrite blindly. Do not. Apply field-level rules that distinguish filling a blank field from changing a populated one.
- Blank website in CRM, canonical website returned: fill automatically.
- Populated website in CRM matches canonical: no-op.
- Populated website in CRM differs from canonical: route to review; do not overwrite. Domain drift is often a rebrand or a subsidiary, not a bad record.
- Blank LinkedIn URL in CRM, canonical URL returned: fill automatically.
- Populated LinkedIn URL in CRM differs from canonical: route to review.
- Multiple CRM rows resolve to the same
business_id: dedup candidate; flag for merge, do not write back until an owner approves.
Step 6, Batch Sizing and Rate Limits
Match accepts up to 50 businesses per call. Firmographics bulk enrich accepts up to 50 business_ids per call. Explorium’s default rate limit is 200 queries per minute per API key, and bulk endpoints count each entity in the payload as a separate query. Two calls of 50 rows each = 100 queries. Under the default limit, a Claude Code loop can process 100 rows per minute end to end. Enterprise customers on higher tiers should confirm their per-account ceiling before turning up parallelism.
Common Variations
Reverse: LinkedIn URL in, everything else out
Send the LinkedIn URL as linkedin_url in the match payload. Same two-call flow returns the canonical website and name.
Website in, LinkedIn out
Send the domain as website in match. Firmographics enrich returns the canonical LinkedIn profile.
Batch mode from a Trigger.dev task or GitHub Action
Wrap the two-call flow in a scheduled task, store the resolved business_id on the CRM record, and skip the match call on subsequent runs. Storing business_id once cuts credit spend on refresh cadences by roughly half.
Why This Belongs in Claude Code and Not a Chat Session
Claude chat is fine for spot-checking a handful of records. It is not the right surface for a repeatable dedup, Sales Nav prep, or CRM identity cleanup workflow. Claude Code brings the file handling, ordered joins across two API responses, confidence-driven routing, and structured CSV output that make this workflow safe to run at 5,000 rows or 50,000. The Explorium API supplies the entity resolution. Claude Code supplies the surrounding logic.
Frequently Asked Questions
How do I match a company name to its canonical website and LinkedIn profile from Claude Code?
Use two Explorium endpoints in sequence. First, POST /v1/businesses/match resolves the fuzzy input (name, or name + website, or LinkedIn URL) to a canonical business_id. Second, POST /v1/businesses/firmographics/bulk_enrich returns the canonical website and linkedin_profile fields for that business_id. Both endpoints accept up to 50 rows per call.
Why does the match endpoint not return the canonical website and LinkedIn URL directly?
The match endpoint’s job is entity resolution: it decides which record you meant given fuzzy inputs and returns the anchor business_id. Returning full canonical fields would slow it down and duplicate the enrichment layer’s job. Two calls keep matching fast and enrichment flexible — you can enrich only the fields you actually need for write-back.
How accurate is name-only matching?
Name alone is the weakest input for Explorium’s match endpoint because there is no domain to anchor the fuzzy resolution. Match accuracy climbs sharply when you include even a partial website or a LinkedIn company URL alongside the name. Route name-only rows that return low-confidence matches to a review file rather than writing them back to the CRM directly.
How many rows can I match and enrich in one Claude Code run?
Both the match endpoint and the firmographics bulk enrich endpoint accept up to 50 rows per call. Explorium’s default rate limit is 200 queries per minute per API key, and each row in a bulk payload counts as one query. Two calls of 50 rows = 100 queries. In practice, Claude Code can process 100 rows per minute end to end under the default limit, and higher throughput on enterprise-tier accounts.
What do I do with rows that return no match?
Route them to a separate unmatched.csv output file with the original input and a reason column. Do not write null values back to the CRM — a null on a populated CRM field is a regression, not an update. Common reasons: name-only input with a very common company name, non-Latin script the fuzzy matcher struggled with, or a defunct entity. Re-run these with additional identifiers (a partial website, a country code, a LinkedIn URL) before falling back to manual review.
