Real-time enrichment

How real-time enrichment works

Real-time enrichment moves the lookup to the moment a record matters. In a batch model, records pile up and a job fills them in later. In a real-time model, an event triggers a lookup for one record, and the answer is written back before the next step runs.

A working setup has four parts.

• A trigger. A form fill, a new CRM record, a stage change or an agent's question starts the lookup.
• A lookup. The system calls an enrichment API with the identifier it has, such as a name and company domain or a profile URL.
• A write-back. Returned fields land on the record, with a timestamp and the source, before routing or outreach reads them.
• A fallback. If the lookup fails or times out, the record continues with what it has and is queued for a later pass.

CRMs build the trigger in. HubSpot can automatically enrich newly created records, for example from forms, integrations or manual creation, and can separately refresh previously enriched records monthly when new data becomes available 1. Those are the two halves of most setups, one live step at creation and one scheduled refresh to fight data decay.

Speed and freshness are different properties. A fast API can still serve a stored snapshot that is months old. RichAPI states that contact and company lookups are fetched live and that only web scraping endpoints cache results server-side 2. Results come back at request time from third-party data sources 2.

Single lookups usually run synchronously, so the caller waits for the answer. Larger jobs run asynchronously. RichAPI's bulk email_finding and email_verification endpoints accept arrays, run as jobs and report back by polling or through a signed webhook 3.

Because the lookup sits on the critical path, errors need a plan. RichAPI returns 429 with a Retry-After header when a per-endpoint rate limit is hit, asks callers to retry 5xx errors with backoff and never bills failed calls 3.

When real-time enrichment is worth it

On RichAPI a live lookup costs the same credits as the same lookup in a bulk call, at 1 credit per profile or company record 4. The added cost is engineering work and a dependency in the path of every new record. Five questions decide whether that trade is worth making.

**Does speed change the outcome?** Inbound routing, lead scoring at creation and a reply drafted while a prospect is on the site all depend on data that exists now. A quarterly list cleanup does not.

**How fast does the field decay?** Job titles and employers change, while a company's industry rarely does. Live lookups pay off on fast-moving person fields. Slow-moving company fields can wait for a scheduled refresh such as HubSpot's monthly continuous enrichment 1.

**Can the stack absorb the call rate?** Every new record becomes an API call. RichAPI's limit starts at 1 request per second on the Sandbox and rises with the credits bought in a month, so peak inbound volume has to fit inside it 4.

**What does a miss cost?** On waterfall endpoints a miss is free. RichAPI email and phone lookups that find nothing cost nothing 3. Single-source enrichment is different. RichAPI profile and company enrichment bill 1 credit per call 34.

**What happens when the lookup fails?** A form should never break because enrichment timed out. Write the record first, enrich second and queue failures for a retry.

Many teams end up with a hybrid. They enrich live where timing matters and run batch jobs for everything else, using the same fields and the same overwrite rules. HubSpot's settings, for example, leave values set manually, by workflows or by integrations untouched when continuous enrichment overwrites older values 1.

Example of real-time enrichment before an outbound send

An outbound team runs a sequence against contacts enriched five months earlier. Before each first email, a workflow refreshes the record so the message goes to the right person at the right company.

Step 1   Read name, company domain, profile URL and last_enriched
Step 2   Call enrich_profile with the profile URL
Step 3   Compare current employer and title with the CRM record
Step 4   If the employer changed, stop and flag for re-routing
Step 5   If the employer is the same, call email_finder
Step 6   Write email, title and last_enriched back to the CRM
Step 7   Release the first email

The refresh costs 1 credit for the profile call 3. The email lookup costs 5 credits per call, and a lookup that finds nothing costs nothing 3. The team budgets for the profile call on every contact and for the email call only where the employer is unchanged.

The employer check is the step that needs live data. A contact who left the company would otherwise receive a message at an old address or a pitch written for a former role. Catching the change at send time keeps the first email away from an address the contact may no longer use.

Each email_finder response includes an execution log that lists the providers tried, their status and their latency 3. The workflow stores the provider that answered next to the email, so a later bounce can be traced to its source.

When the workflow hits the rate limit during a busy hour, it waits for the Retry-After interval and tries again 3. The send waits briefly. Nothing goes out on stale data, and the next refresh can still run as a batch on the rest of the database through waterfall enrichment.

Real-time vs batch enrichment

Both fill the same fields from the same kinds of sources. Real-time enrichment runs one lookup when a record is created or used. Batch enrichment runs many lookups on a schedule, as in HubSpot's monthly continuous refresh 1.