Design a controlled FullEnrich, n8n, and CRM enrichment workflow

Updated November 7, 2026. Design-level tutorial based on official documentation. Untested: no accounts, credentials, API calls, or sending automation were used. The workflow stops at approved CRM data changes.

The goal is narrow: propose a missing work email for an existing, qualified CRM record while preserving identity, suppression, and human ownership. The CRM remains authoritative. Enrichment produces a candidate value, not an instruction to contact someone.

FullEnrich documents asynchronous enrichment, result retrieval, and Bearer authentication. n8n documents the HTTP Request, Webhook, and Wait building blocks. Those sources support the design route below; they do not establish that this article is a ready-to-import workflow. Authentication - FullEnrich API Documentation How Webhooks Work - FullEnrich API Documentation Get Enrichment Result - FullEnrich API Documentation HTTP Request Webhook Wait

1. Write the input and acceptance contract

Start with a small authorized population. Require a stable CRM ID, sufficient person/employer identity, an approved processing purpose, and a missing or expired work-email field. Exclude suppressed records, ambiguous matches, and records outside the permitted population before purchasing data.

For this design, choose an explicit verification allowlist and send every other state to review. Do not accept a record merely because a preferred-email field is populated. FullEnrich documents separate verification states; your acceptance policy must map those states to a business decision. Email Verification Status - FullEnrich API Documentation

Record the policy version on every job. Otherwise a rule change halfway through a batch can produce records that appear comparable but were accepted under different standards. Decide whether in-flight jobs finish under the original policy or move to the new one; keep that decision visible.

2. Prepare three stores before building nodes

Use an authoritative CRM, a durable job ledger, and a proposal queue. The ledger should include internal job identity, CRM identity, requested field, input version, submission state, provider job ID, timestamps, and the outcome. The proposal queue should include the proposed value, evidence, verification status, policy decision, and reviewer disposition.

These are proposed application records, not FullEnrich request fields. Store secrets outside all three. Restrict raw response retention and execution-log access so troubleshooting does not create an uncontrolled contact database.

Capture the existing CRM value and version before work begins. A blank field today can be filled by a rep before enrichment finishes. Guarding against that race is more important than saving one read operation.

3. Configure credentials and the HTTP building block

FullEnrich's authentication documentation specifies an API key in the Authorization header using Bearer authentication. n8n's HTTP Request node supports credential configuration and request parameters. Configure the credential store rather than placing a key in a note, pasted URL, or exported workflow. Authentication - FullEnrich API Documentation HTTP Request

Use a dedicated integration identity with the minimum CRM rights needed for the pilot. Separate development and production credentials and ensure the person reviewing proposals does not need access to the enrichment secret. Establish rotation and revocation ownership before turning on a production schedule.

This article does not provide a credential or runnable request. Copy the method, URL, required fields, and supported types from the current official Start Bulk Enrichment schema. Request only the needed work-email field. Do not copy a documentation example's phone and personal-email requests simply because they appear in the example.

4. Gate and reserve each job

At intake, validate identity and suppression, then acquire an internal deduplication lock. If the same CRM record and policy window already has a submitted or completed job, route the duplicate to reconciliation instead of buying the lookup again.

Write a pending ledger row before the external submission. After receiving the provider job ID, persist it immediately. Keep an explicit unknown-outcome state for the interval where the provider may have accepted work but the client did not record the response. This application-level design does not assume provider-supported idempotency.

Bound the pilot by records, requests, elapsed time, and approved spend. Stop intake when any bound is reached. A budget alarm after the entire batch has already been submitted is too late to control that batch.

5. Submit using the official operation

The documented bulk operation accepts enrichment requests and supports correlation data; use the linked schema to implement the current mapping. FullEnrich returns results asynchronously. Start Bulk Enrichment - FullEnrich API Documentation How Webhooks Work - FullEnrich API Documentation

Treat the accepted submission as the beginning of a job, not its successful completion. Persist the input version and correlation identity so the later result can be matched back to the same record. Avoid putting sensitive notes into correlation fields when a stable internal ID is sufficient.

A submission failure must be classified. Validation problems go to a repair queue. Authentication problems stop the integration. A transient transport problem goes to bounded reconciliation. Do not automatically submit the same paid work again because a browser or workflow view looks empty.

6. Receive completion safely

n8n provides separate test and production webhook URLs. Test with synthetic records and the test URL before configuring a production callback. Webhook

FullEnrich documents batch completion and contact-level webhook options. Choose one primary processing route and deduplicate any additional events you turn on. How Webhooks Work - FullEnrich API Documentation

Do not presume a secret-looking URL authenticates the sender. Verify the authentication mechanism supported by both sides. If the callback's authenticity is not established, treat it as a notification and retrieve the result through the authenticated result operation using the job ID already in your ledger. Reject any callback that refers to an unknown job. Get Enrichment Result - FullEnrich API Documentation

Acknowledge received events only after they are durably recorded, then process them separately where your implementation permits. Store a receipt identifier or deterministic event fingerprint to make repeat delivery harmless. These are editorial reliability controls, not vendor guarantees about webhook delivery.

7. Limit requests and reconcile stale jobs

The published FullEnrich limits are 60 API calls/minute, up to 100 contacts per enrichment bulk, and a default enrichment queue of 100 concurrent contacts. Treat these as independent ceilings. Share a limiter across submission and result-retrieval paths. Rate Limit - FullEnrich API Documentation

Maintain headroom instead of running at the published maximum. Apply bounded exponential backoff with jitter for temporary errors and honor documented server retry guidance where present. Do not invent a fixed retry interval or promise of automatic retry support in the provider.

Run reconciliation on jobs that have remained incomplete beyond your own configured threshold. Retrieve their state using the documented result operation. Escalate unresolved jobs after a bounded number of attempts. Keep reconciliation separate from resubmission so a missing callback does not become a second paid order. Get Enrichment Result - FullEnrich API Documentation

8. Normalize into a proposal, not a CRM overwrite

Validate the returned identity, field format, verification state, and observed time. Preserve the original vendor status. Recheck suppression before creating the proposal; an opt-out or deletion request can arrive after submission.

For this design, the reviewer sees the old value, proposed value, identity evidence, verification state, source service, and job timestamp. They may approve, reject, or request identity repair. A rejection should have a reason so later jobs do not repeatedly purchase the same unsuitable answer.

A reviewer approving a field is not approving outreach. Do not attach a sender, campaign, or automatic next-contact step to this workflow. The output is a controlled data update only.

9. Commit with a version check and a reversible batch

Before writing, read the current CRM version and suppression state again. If either changed, hold the proposal. Otherwise write only the approved field and its allowed provenance metadata, then record the resulting version in the ledger.

Use the target CRM's current official documentation for the exact lookup, permission, and update operations. This tutorial intentionally leaves the CRM adapter abstract: it does not invent endpoints or assert a tested connector for a particular CRM.

Tag each applied change with an internal batch identity. Rollback should compare the current value with the value your workflow wrote, restoring the captured previous value only if no later legitimate edit intervened. If there was an intervening change, create a manual reconciliation task. Blindly restoring an old spreadsheet is not a safe rollback.

10. Add error handling and an operator runbook

n8n documents an Error Trigger workflow selected in Workflow Settings. Use it to create an internal incident record or approved alert path; no alert or message was sent in preparing this article. Handle errors gracefully

The runbook should identify who may pause intake, who can rotate credentials, who resolves identity conflicts, and who authorizes a higher spending cap. Include a restore procedure for the ledger as well as the CRM. A backup that cannot reconnect job IDs to records is incomplete.

Keep operational alerts free of full contact details where a job ID is enough. Review log retention and failure payloads explicitly; error traces can contain the same sensitive data as successful responses.

Untested pseudocode

The names below are conceptual application functions. They are not vendor API methods, a payload schema, or working n8n code.

for each approved input record:
    if suppressed(record) or identity_ambiguous(record): hold
    if existing_job(record, field, policy_window): reconcile_existing
    else:
        reserve_internal_job(record_version, policy_version)
        submit_using_current_official_schema()
        persist_provider_job_identity_or_mark_unknown()

on completion signal:
    locate_known_job()
    retrieve_authenticated_result_if_origin_unverified()
    ignore_already_processed_result()
    recheck_suppression_and_identity()
    stage_candidate_with_original_status()

on human field approval:
    recheck_record_version_and_suppression()
    if changed: hold_for_reconciliation
    else: commit_only_approved_fields_and_record_batch()

Pilot acceptance checklist

Use synthetic fixtures for a duplicate event, missing identity, changed employer, unacceptable status, exhausted budget, lost submission response, duplicate callback, and a CRM edit made during the wait. Include a suppression request arriving between approval and commit. Confirm each case leaves an explainable state.

Then use a small authorized live sample under a cap. Compare the ledger's submitted jobs, vendor billing, staged proposals, approvals, and committed changes. Investigate every unexplained difference before expanding. No such pilot has been run for this article.

Success means accepted records remain traceable and recoverable, including when something fails. Read waterfall enrichment for acceptance economics, n8n vs Zapier for orchestration budgeting, and the tools hub for alternative architectures. Open marketing ops jobs for the role that usually owns this system.

Sources

Primary pages consulted on November 7, 2026. A link supports the claim next to it. It does not prove a customer uses the product.

• Authentication - FullEnrich API Documentation (S28, checked 2026-11-07)
• How Webhooks Work - FullEnrich API Documentation (S29, checked 2026-11-07)
• Get Enrichment Result - FullEnrich API Documentation (S34, checked 2026-11-07)
• HTTP Request (S24, checked 2026-11-07)
• Webhook (S26, checked 2026-11-07)
• Wait (S27, checked 2026-11-07)
• Email Verification Status - FullEnrich API Documentation (S31, checked 2026-11-07)
• Start Bulk Enrichment - FullEnrich API Documentation (S33, checked 2026-11-07)
• Rate Limit - FullEnrich API Documentation (S32, checked 2026-11-07)
• Handle errors gracefully (S25, checked 2026-11-07)