GTM Galaxy

Article

The Zero-Waste Enrichment Waterfall: Building a Cache-First Pipeline in n8n

Claudine Baumbach / / Pacific

Most GTM teams scale their enrichment the same way: they plug a Salesforce webhook into an enrichment tool and walk away. This works until you start running high-volume outbound or account-based plays. Suddenly, your enrichment budget vanishes by the second week of the month, and your CRM audit logs look like a crime scene where three different vendors are fighting for control of the 'Industry' field.

The problem is naive, concurrent execution. When a lead hits your system, firing off simultaneous calls to Apollo, Clearbit, and Lusha is technically messy and commercially reckless. You end up paying for the same firmographic data multiple times while dealing with 'write flapping'—where different vendors provide slightly different company names, causing your CRM data to oscillate between values and trigger redundant downstream automations.

The fix is a stateful, sequential waterfall. By using n8n as the orchestrator and a PostgreSQL database as your 'GTM memory,' you can build a pipeline that checks a local cache first, validates the input, and only hits external APIs when absolutely necessary.

The Anatomy of the Wasteful Call

Blindly sending every email to an enrichment endpoint is an easy way to burn credits. Two specific habits drive most of the waste:

  1. The Freemail Tax: Sending john.doe@gmail.com to a firmographic endpoint usually returns junk or a 'no match,' but some providers still count the lookup against your rate limits. Worse, if you’re using a person-level search, revealing a mobile number can cost 8x more than a standard email reveal (a common Apollo credit tiering model).
  2. Domain Amnesia: If a lead from acme.com signs up today and another joins tomorrow, there is zero reason to pay for the same firmographic data again. Company headquarters and employee counts don't change daily.

Step 1: Normalization and the 'Early Exit'

Your first node in n8n shouldn't be an API call; it should be a Code node. You need to strip subdomains and filter out 'freemails' or disposable domains before they touch your budget.

// Simple domain normalization in an n8n Code Node
const freemails = ['gmail.com', 'outlook.com', 'yahoo.com', 'hotmail.com'];
const email = items[0].json.email;
const domain = email.split('@')[1].toLowerCase();

return {
  domain: domain,
  is_personal: freemails.includes(domain),
  should_enrich_firmographic: !freemails.includes(domain)
};

If is_personal is true, you route the lead away from firmographic vendors and toward a person-level lookup or a manual research queue. This single branch typically saves 20–30% of API volume for B2B signups.

Step 2: PostgreSQL as the GTM Cache

You don't need a heavy data warehouse. A single PostgreSQL table acts as a high-speed cache. The goal is to store firmographic data with a timestamp to manage your Time-To-Live (TTL).

CREATE TABLE firmographic_cache (
  domain TEXT PRIMARY KEY,
  company_name TEXT,
  industry TEXT,
  employee_count INT,
  headquarters_country TEXT,
  last_enriched_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

In n8n, use a PostgreSQL Select node to check if the domain exists and if the data is fresh (e.g., enriched within the last 90 days).

SELECT * FROM firmographic_cache 
WHERE domain = $1 
AND last_enriched_at > NOW() - INTERVAL '90 days';

Step 3: Implementing the Waterfall Logic

This is where you build the sequential logic. Instead of parallel calls, your n8n workflow follows this path:

  1. Check Cache: If a fresh record exists, use it and move to the CRM write node. (Cost: $0.00).
  2. Vendor 1 (The Generalist): If the cache is empty or stale, call your most cost-effective provider (e.g., Apollo).
  3. Conditional Branch: Check if Vendor 1 returned the required fields (like industry or employee_count).
    • If Yes: Update the PostgreSQL cache and move to the CRM write node.
    • If No: Proceed to Vendor 2 (The Specialist).
  4. Vendor 2 (The Specialist): Call your high-fidelity, high-cost provider (e.g., Clearbit or ZoomInfo). Update the cache and exit.

This sequential approach ensures you only use your most expensive credits for the hardest-to-find data.

Step 4: The Unified CRM Write

To stop write flapping, you must decouple enrichment from your CRM updates. In a naive setup, every API call triggers an independent PATCH request to your CRM. This causes data race conditions where internal automations (like lead scoring) fire multiple times for one lead.

In the waterfall model, you maintain a single JSON object representing the 'Best Available Data' as it moves through the nodes. You only perform a single CRM update at the very end of the workflow. This ensures that your lead assignment rules and Slack alerts trigger exactly once, using the most complete data set available.

Addressing the Trade-offs

The primary counterargument to a sequential waterfall is latency. If Vendor A takes 2 seconds and Vendor B takes 2 seconds, a lead might take 5+ seconds to process.

For 99% of B2B use cases, this is a non-issue. A sales rep doesn't care if a lead is assigned in 1 second versus 6 seconds. However, if you are running real-time website personalization (e.g., changing a demo calendar based on company size), the 5-second delay is unacceptable. In that specific scenario, parallel execution is the price of performance. For everything else—routing, scoring, and outbound—deterministic data and credit preservation are the priority.

Building for Maintenance

By moving this logic into n8n, you gain an observability layer that vendor-native integrations lack. You can see exactly which vendor is failing to provide matches and adjust your waterfall order in minutes without touching CRM code.

You stop being a passenger to your data providers' pricing models. You own the logic, you own the cache, and you only pay for the data you actually need.

— C.B.