Batch Enrichment vs Real Time: Choose the Right Workflow

Batch enrichment vs real time is a workflow design choice. You are deciding when a record needs new data, which fields change an operational decision, and whether a person should review the result before it reaches your CRM or another system.

Batch enrichment vs real time: the core difference

Batch enrichment processes a prepared set of records, while real-time enrichment resolves data in response to an event or request.

A batch starts with a known list. You may have a CSV export from a CRM, a target-account list, or records that need a specific missing field. You choose identifiers, select the fields to return, review the expected cost, and run the list as a unit.

A real-time workflow starts because something happened. A form submission created a lead. A sales rep needs account context before a meeting. An agent receives a request to find people matching a description. The result feeds a decision already in progress.

Neither approach is inherently better. The right choice depends on the operational decision that follows.

• If the decision can wait for a scheduled review, batch enrichment is usually the clearer path.
• If an assignment, qualification step, or research task depends on the result now, use real-time enrichment.
• If you need both, separate their responsibilities rather than forcing a single workflow to do everything.

A hybrid model is common. You can use a scheduled process for CRM cleanup and a real-time call when a newly created record reaches routing. The scheduled process reduces old gaps. The event-triggered process makes the record more useful at the moment someone needs to act on it.

Data freshness matters in both cases. Enrichment is live, so the same query can legitimately return different data later. That makes refresh timing a business rule, not just a technical setting.

Choose batch enrichment for planned data maintenance

Choose batch enrichment when you have a prepared record set and want control before changes reach downstream systems.

This is a good fit for work such as:

• Onboarding a new prospect or account list.
• Filling governed CRM gaps.
• Refreshing target-account context before planning.
• Preparing a campaign audience.
• Reviewing records that have incomplete title, department, location, or company information.
• Adding company context to people who share the same employer.

CSV enrichment supports this workflow directly. You upload a list, map your existing columns to identifiers, choose the fields you need back, and see a cost preview before the run starts. That review step matters when your source data contains a mix of strong and weak identifiers.

For people, usable identifiers include:

• A LinkedIn URL.
• A work email address.
• A name plus employer.

For companies, you can resolve records from:

• A company domain.
• A company name.
• A company LinkedIn URL.

Column mapping gives you a chance to check what each input value means before enrichment begins. A column called Company might contain a legal entity name, a domain, or free-text notes. Treating those as interchangeable creates avoidable mismatches. Map the column to the identifier it actually contains.

Choose fields based on the intended action. A campaign-preparation workflow may need title, seniority, department, location, company, and company_domain. A company review may need company fields and the firmographics that ride along on a company row.

When a workflow should not automatically overwrite CRM values, export the result for review first. Compare the returned value with the value already in your system. Then apply your own update rules:

• Fill an empty field.
• Send conflicting values to a review queue.
• Preserve a value maintained by a trusted internal process.
• Record when the enrichment result was received.
• Keep the identifier used for the lookup with the result.

The CSV route is useful because it separates enrichment from your eventual writeback. You can inspect the enriched file before another process imports it.

Choose real-time enrichment when a workflow cannot wait

Choose real-time enrichment when a record reaches a decision point and the workflow needs additional context to proceed.

Common examples include:

• Qualifying an inbound lead.
• Researching an account before a meeting.
• Adding lead routing data to a newly created record.
• Resolving an identifier held by a sales or operations workflow.
• Running agent-assisted research through the in-product chat agent or MCP server.

Real-time does not mean every request needs immediate inline results. It means the workflow begins in response to a current event.

With the REST API, a small request can answer inline. A search asking for ten results or fewer, or an enrichment of five rows or fewer, returns with results already populated and a terminal job.status.

Larger requests are queued. Requests that ask for the email field are queued as well. A request is also queued when you send async: true or Prefer: respond-async. In those cases, results is null until you poll the job.

That distinction helps you design the calling workflow correctly:

• For a small meeting-prep lookup, use the result already returned when the job is terminal.
• For a larger routing backfill, store the job ID and process the result when polling reaches a terminal status.
• Do not build a polling loop for a request that already returned inline results.
• Do not assume that an event-triggered workflow requires a synchronous response.

Request only the fields that change the immediate decision. If routing depends on department and seniority, request those fields. If a rep needs employer context, request company, company_domain, or company_profile as appropriate. Avoid adding fields merely because they are available.

Work email addresses require a deliberate request. Ask for email by name. An address is returned only when found, and it comes with an email status: verified, probable, unverified, risky, undeliverable, or unknown.

Decide based on the trigger, decision, and acceptable delay

Use the trigger, the consumer, and the acceptable delay to choose an enrichment workflow.

A useful design review starts with four questions:

1. What triggers enrichment?
   A scheduled cleanup, file upload, form submission, sales request, or routing event each creates different timing and review needs.

2. Who consumes the result?
   The consumer may be an operations reviewer, a CRM process, a sales rep, or an agent tool call.

3. What happens if no data is returned?
   Your workflow should continue with a defined fallback rather than treating every unresolved record as a system failure.

4. Does a human need to review the result?
   If the answer is yes, batch export and a review queue are often safer than automatic updates.

A scheduled CRM cleanup is usually a batch process. The records already exist, and the goal is to fill or refresh fields under controlled rules. The acceptable delay is often longer because the work is maintenance rather than an immediate customer interaction.

A form submission is different. You may need title, department, company, or location before assigning the record. That is a real-time enrichment case, but it still needs a fallback. If no field is resolved, route the lead using the data already collected rather than blocking the process.

A sales-rep research request is also real-time, but the consumer is a person rather than an automated router. The right response may be a small inline lookup, a queued job for a larger request, or a chat-agent run that returns a table for export.

A lead-routing event needs the narrowest set of decision fields. Do not turn it into a broad profile collection exercise. If seniority and department determine ownership, ask for those. If the result is absent, assign the record to a default queue or preserve the existing assignment.

The fallback path should be explicit for every workflow:

• Keep the source value when enrichment returns nothing.
• Mark the record for later batch review.
• Send it to a general queue.
• Continue without enrichment when the next step does not depend on it.
• Avoid retrying without a reason that changes the expected result.

Design identifiers and fields for each workflow

Use the strongest identifier you already hold, then request fields tied to a defined action.

For a person record, a LinkedIn URL is useful when you have a specific profile. A work email can identify a person for reverse email lookup. A name plus employer is appropriate when neither of those is available, though you should keep the employer value clean and recognizable.

For a company record, use a company domain when you have one. A company name or company LinkedIn URL can also resolve a company record.

Field selection should follow the decision you are making:

• Use title when a current role affects qualification or research.
• Use seniority when assignment or segmentation depends on a normalized band.
• Use department when ownership or messaging depends on functional area.
• Use location and country when geography matters.
• Use company and company_domain to connect a person to an employer.
• Use linkedin_url when the workflow needs the result’s own LinkedIn URL.
• Use headline when profile or company description is relevant.

The people field catalogue is closed. A field outside the available set is a validation error, not an empty column. Treat that as a design constraint: define the operational output before building the request.

Ask for email explicitly when a work address is required. It is billed only when an address is found, and deliverability checking is included for each returned email. Do not treat a missing address as a failed record. The person may still resolve with other requested fields.

Use company_profile deliberately when you need employer context for people. It returns the employer’s own record nested under company, including industry, headcount, founded year, description, annual revenue, total funding, latest round, and monthly visits. The lookup is shared for people with the same employer, so you are billed once per company rather than once per attribute.

Mobile numbers are different. The phone field is available only when requested by name, sourced from a LinkedIn profile URL, and billed only when found. It has no deliverability verdict. A number being available is not a representation that it is lawful to call; compliance with TCPA, DNC registries, and local consent rules remains your responsibility.

Build safe API workflows for queued enrichment

For queued enrichment, read job.status from the job object and treat results as unavailable until the job reaches a terminal status.

Every search, enrichment request, and job poll returns the same response envelope:

{
  "job": {
    "object": "job",
    "id": "…",
    "type": "…",
    "status": "queued",
    "fields": ["title", "department"],
    "requestedCount": "…",
    "resultCount": "…",
    "creditsUsed": "…",
    "error": null,
    "createdAt": "…",
    "startedAt": null,
    "finishedAt": null,
    "url": "…"
  },
  "results": null,
  "page": null,
  "estimatedCredits": "…"
}

There is no top-level id or top-level status. Read job.status.

When work is queued, poll:

GET /api/v1/jobs/{id}

The poll endpoint always answers with HTTP 200. The meaningful state is in job.status.

Handle these terminal statuses explicitly:

• succeeded: results are available.
• empty: the job completed without delivered results.
• failed: inspect the job error and send the record to your fallback path.
• cancelled: stop processing and decide whether a later run is appropriate.

A terminal result contains wrappers rather than bare person or company rows:

{
  "position": "…",
  "status": "succeeded",
  "data": {},
  "evidence": "…",
  "error": null
}

The resolved person or company data is inside data. Each wrapper also has its own item status: pending, running, succeeded, not_found, or failed.

For paged results, use the opaque forward-only cursor supplied in page. Do not construct or alter a cursor yourself.

Retries need an idempotency rule. Send the same Idempotency-Key header when retrying the same request. That retry is deduplicated. Without the same header, a retry is a new request: it creates a second job, takes a second hold, and can be charged separately.

The REST API, including its generated OpenAPI document, is available under /docs and /api/v1/openapi. Enrichments also exposes the same credit balance and validation layer through the MCP server, chat agent, and CSV workflow.

Control costs, freshness, and CRM changes in a hybrid model

Use batch runs to reduce a backlog and real-time calls for records that have reached a decision point.

This division keeps cost and workflow intent visible. A batch run can target known CRM gaps or a prepared audience. A real-time request can resolve the small set of fields needed for routing, qualification, or research.

Billing follows delivered data:

• A people search is charged at 0.25 credits per returned person.
• A company search is charged at 0.5 credits per returned company.
• A resolved person enrichment row is charged at 0.5 credits.
• A resolved company enrichment row is charged at 1 credit.
• A returned work email is charged at 2 credits.
• A returned mobile number is charged at 10 credits.
• An unresolved enrichment row does not create a data charge.

A search is different from enrichment because the returned identity is the delivered unit. Design searches with a clear audience definition and a count appropriate to the next workflow step.

Repeated questions inside the cache window are charged at 0. Use that behavior carefully. A cached answer is useful when the question has not changed. It is not a substitute for a refresh policy when data freshness matters.

Keep the same controls across every entry point:

• Record the source identifier.
• Record which fields were requested.
• Preserve returned evidence where your process needs it.
• Define which CRM fields can be filled automatically.
• Define which conflicts require review.
• Keep unresolved records on a fallback path.
• Apply the same rules whether the run started through the enrichment API, MCP, chat, or CSV upload.

A hybrid enrichment workflow works best when it is explicit. Batch processes maintain the records you already have. Real-time workflows support decisions happening now. The fields, review rules, and fallback behavior should be consistent across both.