Developers and AI engineers building agent workflows in Codex hit the same wall RevOps teams do at scale: the CRM has partial company records and the Codex context window is too small to enrich them at scale. This guide shows how to call the Explorium business enrichment API from inside Codex, from single-row match through bulk export, with confidence rules that keep bad matches out of production data. Two paths are covered: direct HTTP against Explorium’s endpoints, and the Vibe Prospecting Plugin (the MCP wrapper).
What Business Enrichment in Codex Actually Means
Business enrichment is not a spreadsheet lookup. It is a controlled API workflow that separates three decisions: resolving the partial input to a canonical company identity, filling missing firmographic and technographic fields with data that meets a confidence threshold, and exporting only the rows that justify the change.
Why the distinction matters for Codex agents
Many enrichment SDKs treat every row the same. They accept a domain, return something that looks close, and move on. Inside a Codex agent workflow, that behavior creates operational problems. An incorrect industry field routes an account to the wrong campaign. A stale headcount breaks lead scoring. A wrong parent-company link disrupts account ownership in the CRM. A duplicate account makes revenue reporting unreliable.
Business enrichment in Codex works differently because Codex provides file handling, subagent orchestration, and controlled write-back. The workflow knows what input fields exist, what confidence level justifies an update, and where the enriched output goes next. That is the difference between an enrichment run that improves GTM operations and one that just adds noise.
Where the direct-API path fits versus the Vibe Prospecting Plugin path
The Vibe Prospecting Plugin is the MCP wrapper around the Explorium API. It is the right tool for interactive enrichment inside a Codex session: it enforces sample-before-export, surfaces credit usage in the response, and requires no key handling in your script. The direct-API path is the right tool when the enrichment is a scheduled job, a GitHub Action, or a subagent that runs outside a chat session. Both hit the same Explorium endpoints and the same credit pool. This guide covers both, starting with the direct-API path because that is where Codex power users hit the highest scale.
How the Explorium API Enables Business Enrichment in Codex
Explorium’s AgentSource API is the underlying REST surface. For business enrichment specifically, four endpoints do the work: match resolves partial company inputs to a canonical business_id, firmographics bulk_enrich returns firmographic fields for a batch of IDs, technographics bulk_enrich returns the tech stack, and the events endpoint layers buying-signal events. The Vibe Prospecting Plugin exposes the same endpoints as MCP tools when you prefer a plugin call over raw HTTP.
What the API accepts as input
The strongest single match signal is a company domain. Domains drift less than names across subsidiaries, rebrands, and regional variations. Company name plus domain is Explorium’s recommended combination — the match endpoint applies smart fuzzy logic on the name and uses the domain as an anchoring signal. Domain alone is the fallback. Name alone is the weakest single input. Including the CRM account ID in every row is non-negotiable: it is the anchor that ties the enriched result back to the correct CRM record.
What the API returns
Once a strong match exists, the API can fill 4,000+ firmographic and technographic fields per company profile, including company domain, industry, employee headcount, revenue range, country, region, tech stack, funding rounds, parent-company relationships, and 18 categories of buying signals. These fields support routing, scoring, segmentation, and outbound sequencing decisions that depend on reliable GTM data.
Step 1, Set Up the API Key in Codex
Get an API key from the Vibe Prospecting dashboard (free tier is 400 credits valid 90 days, no credit card required), then put it in your Codex project’s environment as EXPLORIUM_API_KEY. Codex loads the key automatically for subagents and shell commands that need it. Never hard-code the key in a script. Never commit the env file. Rotate the key from the Vibe Prospecting dashboard if it leaks.
Step 2, Standardize the Input File
Business enrichment in Codex begins with existing account records, not net-new prospecting. The starting export may have partial domains, name-only rows, missing countries, or blank industries. That is the normal state of CRM data. You do not need perfect input; you need enough context to make reliable matches.
Ask Codex to lowercase all domains, strip URL scheme prefixes and the www. subdomain, and preserve the original CRM account ID on every row. That single normalization pass raises match rates 5-15% on messy CRM exports.
Step 3, Sample Before Export
Before spending credits on a large batch, call the Explorium statistics endpoint on the input to get a distribution and coverage estimate for the target segment. Codex returns the estimate to the operator; the operator approves before the enrichment loop fires.
Step 4, Match to a Canonical business_id
Call the match endpoint in bulk. Send the list of businesses (name plus website is the recommended combination; website alone is the fallback). The response preserves the input order and returns a canonical business_id per row. Rows that resolve become the input to enrichment; rows that miss go to a review file until a human approves them.
Step 5, Enrich Firmographics and Technographics
Pass the resolved business_id batch to the bulk enrichment endpoints. Each enrichment type is its own endpoint — firmographics, technographics, funding, workforce trends, etc. — so a full profile chains several calls per batch. Each endpoint accepts up to 50 business IDs per call and sustains 100 QPS across the account. Results do not flow through the Codex chat context, so an account file with 10,000 rows finishes in a script loop, well under the rate ceiling and completely bypassing the token budget.
Step 6, Layer Buying-Signal Events
Optional but recommended for outbound workflows. Call the events endpoint to layer 18 buying-signal categories (hiring, funding rounds, tech installs, website changes) onto the enriched set. Batch up to 20 business IDs and 10 event types per call. Prioritize fresh events (last 30 days) for outbound sequencing.
Step 7, Export Approved Rows Only
Apply field-level update rules that distinguish between filling blank fields and changing populated ones. For blank fields, high-confidence matches can update automatically. For populated fields, compare the existing value against the enriched value and flag any difference as a conflict requiring human review. Setting the update action to update-blank-fields-only for high-confidence rows, and review-required for any row where the enriched value differs from an existing CRM value, prevents the workflow from overwriting trusted data.
The workflow produces two output files: approved_enrichments.csv for high-confidence rows and review_required.csv for weak or conflicting matches.
Example Output Schema
| Field | Source | Update action |
|---|---|---|
crm_account_id | Input | Anchor for write-back, never overwritten |
business_id | match endpoint | Stored on CRM for future re-enrichment |
match_confidence | match endpoint | Routes the row to approved or review file |
domain | firmographics enrich | Update blank only; conflicts to review |
employee_headcount | firmographics enrich | Update blank only; conflicts to review |
industry | firmographics enrich | Update blank only; conflicts to review |
tech_stack | technographics enrich | Append; do not overwrite |
recent_events | events endpoint | Append; scored by recency |
How to Decide What Gets Written Back
Confidence levels control write-back. High-confidence matches with blank target fields update automatically. Medium-confidence rows go to the review file. Weak matches stay out of the CRM entirely. Owner fields, lifecycle stage, and account associations should never be updated automatically regardless of confidence level.
Common Variations
Greenfield enrichment (no CRM input)
Skip standardization and call the fetch endpoint to pull a target list from Explorium’s 150M+ company profiles, then jump to Step 5 (enrich).
CRM refresh on a schedule
Wrap the workflow in a GitHub Action or scheduled task runner. Store the resolved business_id on the CRM to skip the match call on subsequent runs and cut credit spend 30-50%.
Outbound handoff
Route enriched rows with fresh buying-signal events to an outbound sequence tool via API. Prioritize rows scoring highest on recency and signal strength.
Why Business Enrichment Works Better as an API Workflow Than a Chat Task
Codex chat is useful for reviewing a small sample of enriched rows or debugging a match rule. It produces conversational output. Business enrichment at scale requires file handling, transformation logic, confidence rules, export formats, and CRM write-back. Codex with the Explorium API (or the Vibe Prospecting Plugin wrapper) handles all of those. For repeatability across thousands of records, and for scheduled jobs that run without a human in the chat, the API path is the right tool for the job.
Frequently Asked Questions
What is business enrichment in Codex?
Business enrichment in Codex is the process of using a structured API workflow inside Codex to resolve partial company records to a canonical business identity, fill missing firmographic and technographic fields with data that meets a confidence threshold, layer buying-signal events, and produce clean output files for CRM write-back. The Explorium AgentSource API (150M+ company profiles, 800M+ people, 50+ data sources) provides the matching and enrichment data layer. From Codex you can hit it directly over HTTP or through the Vibe Prospecting Plugin (the MCP wrapper).
How does the Explorium API match a company from partial input?
The match endpoint resolves partial company inputs to a canonical business_id. The strongest single input is a company domain because domains drift less than names. Company name plus country or industry is a reliable secondary input. Company name alone is the weakest and typically routes to a medium-confidence match. Each match returns a confidence level so the workflow can route rows to the approved or review file appropriately.
How do I avoid overwriting good CRM data during enrichment from Codex?
Apply field-level update rules that distinguish between filling blank fields and changing populated ones. For blank fields, high-confidence matches can update automatically. For populated fields, compare the existing value against the enriched value and flag differences as conflicts requiring review. Setting the update action to update-blank-fields-only for high-confidence rows, and review-required for any row where the enriched value differs from an existing CRM value, prevents the workflow from overwriting trusted data. Owner fields, lifecycle stage, and account associations should never be updated automatically regardless of confidence level.
How many businesses can I enrich in a single API call from Codex?
The bulk enrichment endpoints accept up to 50 business IDs per call, sustained at 100 QPS across the account. Chain 20 calls to enrich 1,000 companies in under 30 seconds. Results do not flow through the Codex chat context, so a 10,000-row account file finishes in a script loop instead of overflowing the token budget.
How long does a business enrichment run take in Codex?
Runtime depends on the number of records, the quality of input identifiers, and the enrichment fields requested. A focused segment of 500 to 1,000 companies with clean domains typically completes in under a minute. Larger exports with weaker identifiers take longer because matching requires more disambiguation. Running enrichment in focused segments rather than exporting the entire CRM at once keeps runs manageable and makes it easier to review and act on results quickly.
