A lead fills out your demo form. Thirty seconds later, your routing system needs to know: Is this a mid-market SaaS company? Does this person have budget authority? Should this go to the enterprise team or the self-serve onboarding flow? If your enrichment takes 24 hours to return results, the lead is cold before your rep sees it.

Real-time enrichment APIs return company and contact data in milliseconds, not hours. They're what power instant lead routing, live form enrichment, and automated qualification workflows. If your go-to-market motion depends on speed, batch enrichment won't cut it.

Key takeaways

• Real-time enrichment returns data in under 200ms. Fast enough to enrich a form submission before the "thank you" page loads.

• Use real-time for inbound, batch for outbound. Inbound leads need instant qualification. Outbound lists can wait for batch processing.

• Single-provider APIs cap your coverage. No one provider covers every company or contact. Multi-source APIs give you higher match rates.

• API reliability matters more than speed. A 50ms API that's down 5% of the time is worse than a 200ms API with 99.9% uptime.

Real-Time vs. Batch: When to Use Each

Not every enrichment needs to happen instantly. The cost and complexity of real-time enrichment only makes sense for specific use cases.

Here is the exact handoff scenario: "Form is submitted on site. We need to enrich it, route it, and show the appropriate owner's calendar. That is this trigger." That's real-time enrichment at work. The form submit fires an API call. The API returns company size, industry, and contact details. The routing logic sends it to the right rep. The rep's calendar appears. All in under 2 seconds.

What a Real-Time Enrichment API Returns

A good enrichment API takes a thin input (email address, domain, LinkedIn URL) and returns a full profile. Here's what you should expect:

From an Email Address

• Contact data: Full name, job title, seniority level, department, LinkedIn profile, phone number

• Company data: Company name, domain, employee count, industry, revenue range, HQ location

• Verification: Email deliverability status (valid, invalid, catch-all, unknown)

From a Company Domain

• Firmographic data: Employee count, revenue, industry, founding year, HQ location

• Technographic data: Tech stack, recently adopted/dropped tools

• Growth signals: Hiring velocity, funding history, revenue trajectory

• Social profiles: LinkedIn company page, Twitter, Crunchbase

From a LinkedIn URL

• Profile data: Current title, company, location, experience history

• Contact data: Work email, personal email, phone number

• Activity signals: Recent posts, engagement patterns

How to Evaluate Real-Time Enrichment APIs

Not all APIs are equal. Here's the framework for comparing providers:

1. Match Rate (Coverage)

The most important metric. If the API can't find data on 40% of your requests, speed doesn't matter. Single-provider APIs typically match 50 to 70% of B2B records. Multi-source APIs that cascade across providers push that to 75 to 90%.

Test with your own data, not the vendor's demo. Pull 500 records from your CRM and run them through each API you're evaluating. Compare match rates on the fields that matter to your workflow.

2. Response Time

For real-time use cases, you need sub-second responses. Anything over 2 seconds breaks the user experience on form submissions and live chat.

3. Data Freshness

Some APIs serve cached data. Others query providers in real time. Cached data is faster but may be weeks or months old. Real-time queries are slower but return the latest information. For most B2B use cases, data that's less than 30 days old is acceptable. For contact verification, you want live results.

4. Error Handling and Reliability

Real-time APIs sit in your critical path. When they fail, your lead routing breaks. Evaluate:

• Uptime SLA: 99.9% minimum for production use

• Rate limiting: What happens when you hit limits? Graceful degradation or hard failures?

• Timeout behavior: What does the API return when the upstream provider is slow?

• Fallback logic: Can the API automatically try a second provider if the first fails?

5. Pricing Model

Three common models:

• Per-call pricing: Pay for every API request, regardless of whether data is returned. Cheap per call but expensive if match rates are low.

• Per-result pricing: Pay only when the API returns data. More expensive per enrichment but zero waste on misses.

• Monthly credits: Buy a block of credits upfront. Good if your volume is predictable. Bad if it fluctuates.

Databar uses per-result pricing. You only pay when data is returned. Combined with 100+ data sources cascading in real time, this means high match rates with zero spend on empty results.

Real-Time Use Cases and Their Latency Budgets

If you are new to the category, what data enrichment is covers the fundamentals. "Real time" is not one target. Each use case has a different amount of time before a human notices, and designing to the wrong budget is how teams end up over-engineering a CRM trigger or under-engineering a form.

Form Enrichment

A visitor submits a demo request with a name and a work email. Before the confirmation page paints, you have their title, company, company size, industry and LinkedIn profile.

The full handoff pattern, including how to score and route what comes back, is in our guide to inbound lead enrichment. One call covers the routing and the scoring: enterprise and mid-market go to different teams without anyone triaging by hand, and the enriched company data tells you whether the form fill came from an ICP-fit account or a student doing research. The SDR who picks it up also inherits the full profile, which is what makes a first line possible that references something real.

Chat Qualification

A prospect opens your site chat and the bot asks for an email. The moment they type it, the enrichment fires. By the bot's next question it knows the company, the role and the size, and the conversation forks: an enterprise VP gets handed to a live rep, a solo consultant gets pointed at self-serve docs.

The budget here is tight because the enrichment has to finish between the prospect's message and the bot's reply. Anything over two seconds and the bot looks broken.

Website Personalization

A known contact lands on your pricing page. You identify them by cookie, by email, or by reverse IP, and enrichment fills in the company context so the page can adjust: enterprise visitors see the enterprise tier highlighted, smaller teams see the entry plan.

This is the tightest budget on the list, because the call has to complete before the personalized content renders. It is also the use case where a cache hit matters most.

CRM Triggers

A contact gets created in the CRM by a form, a manual entry or an integration sync. A webhook fires, enrichment fills the missing fields, and by the time an SDR opens the record it is already complete.

The fields worth filling on create are the firmographic base: employee count, industry, revenue band, HQ. Which providers cover those is covered in company data enrichment. Nobody is watching a spinner here, so five seconds is fine. The reason to still call it real time is that doing it on create is far cheaper than doing it in a monthly cleanup, and it stops bad records from entering the database in the first place.

Building Real-Time Enrichment into Your Stack

Architecture Pattern 1: Form Enrichment

The most common real-time use case. A prospect fills out a form. The API enriches the record before it hits your CRM.

1. Prospect submits form (email + company domain)

2. Webhook fires to your enrichment API

3. API returns company size, industry, contact title, and verification status

4. Routing logic assigns the lead (enterprise vs. mid-market vs. self-serve)

5. Enriched record is created in CRM with all fields populated

6. Rep sees fully enriched lead in their queue within seconds

Architecture Pattern 2: CRM Enrichment on Create

Every new record in your CRM triggers an enrichment call. This keeps your database clean from the start instead of running periodic batch cleanups.

1. New contact or company created in CRM

2. CRM webhook triggers enrichment API

3. API fills in missing fields (title, phone, company data, tech stack)

4. Record is updated in CRM automatically

Architecture Pattern 3: AI Agent Enrichment

The newest pattern. AI agents use enrichment APIs as tools in their workflow. An agent processing inbound leads calls the enrichment API, interprets the results, and takes action (route the lead, draft a response, or flag for human review).

Databar's MCP server enables this pattern directly. AI agents like Claude Code can call Databar's enrichment APIs as part of their reasoning chain, making enrichment a native part of agentic GTM workflows.

Designing for Latency: Caching, Timeouts and Failure

Real-time enrichment sits in your critical path. That changes what you have to build around it.

What Caching Does and Does Not Do

Caching is the difference between a 50ms response and a 2s one, so it is worth being precise about how it actually works.

Databar's MCP server caches enrichment results for 24 hours, and a cached lookup does not consume credits. If you want a fresh provider call inside that window, pass skip_cache: true. Those three facts are what the documentation covers, so do not assume anything else about the cache when you are sizing a latency budget.

There are really three places a lookup can be answered, and only two of them are yours to design:

• Your application cache. In-memory, sub-millisecond, small. Worth having for contacts that recur inside a single session or a short window.

• The MCP server cache. 24 hours, free on a hit. This is what makes a repeat lookup through an agent fast, and it is why pre-warming works. It is documented for the MCP server specifically: a direct REST or SDK call goes to the provider.

• The provider call. Cache miss. This is where the real latency lives.

Pre-warming follows directly from that. If you know which accounts are likely to show up (an ABM target list, this week's campaign recipients), enrich them in batch beforehand. When they arrive on the site, the lookup hits the cache instead of a provider. Our guide to batch versus real-time enrichment covers that hybrid pattern.

Separately from caching: task results from headless runs are retained for 24 hours and then permanently deleted. That is retention, not cache. If your architecture submits a job and collects it later, collect it inside the window.

Synchronous or Asynchronous

Synchronous. You send the request and wait. The response carries the data. Right for anything where the calling process is blocked on the answer: form enrichment, chat qualification, personalization.

Asynchronous. You submit and get a task ID back, then poll or receive the result later. Right when nothing is blocked: CRM triggers, background backfill, anything batch-shaped.

For sub-second use cases, synchronous is the pattern. The Python SDK's _sync methods submit and poll for you, so synchronous is also the less code-heavy option.

Never Let Enrichment Break the Form

The safeguards, in order of how often they save you:

• Hard timeout. If enrichment has not answered in three seconds, continue without it. A demo request must never fail because a provider was slow.

• Partial results. If you have the company but the phone lookup is still running when the timeout fires, take the company and backfill the phone later.

• Graceful degradation. If enrichment is down entirely, the lead still enters the CRM. A background job picks it up. Enrichment is an enhancement, never a hard dependency on a user-facing flow.

• Circuit breaker. After five consecutive failures, stop calling for sixty seconds and use the fallback path. This is what stops one provider outage from turning into a queue of timing-out form submissions.

Shaving the Milliseconds

Request only what you need. If lead routing needs company size and industry, do not also ask for phone and social profiles. Fewer fields can mean fewer provider calls.

Pool your connections. A cold TCP handshake plus TLS negotiation costs 100 to 300ms. With a persistent connection that disappears after the first request. In Python, reuse one client instead of constructing a new one per call, and use it as a context manager so the pool closes cleanly.

Mind the geography. Cross-country round trips add tens of milliseconds before anyone has done any work. It is the cheapest thing to fix and the easiest to forget.

How Waterfalls Behave When You Are in a Hurry

A waterfall tries providers in the order you configured and stops at the first one that returns a usable result. That is true in batch and in real time. The consequence for a latency-sensitive path: a waterfall's worst case is the sum of every provider it has to try. If the first three miss, you have paid three round trips before the fourth answers.

So the ordering advice changes depending on what you are optimizing for. For a batch job, order by cost: cheapest and highest coverage first, because you only pay the expensive provider on the rows the cheap one missed. For a real-time path, order by latency times coverage, and trim the chain. A four-provider waterfall on a form submission will occasionally blow your budget. Two providers plus a hard timeout will not.

Providers can be reordered and switched off individually in the waterfall setup, which means you can run a short, fast chain on the inbound path and a long, thorough one on the nightly backfill of everything the fast chain missed. That combination gets you the coverage without the latency. More on the mechanics in how waterfall enrichment works.

What to Monitor Once It Is Live

Real-time enrichment fails quietly. The form still submits, the lead still lands, it is just empty. Put these on a dashboard:

• P95 latency, not average. The average hides the tail, and the tail is what your users experience as broken.

• Error rate, split by cause: timeout, provider error, not found. A spike in one of those three tells you a very different story than a spike in another.

• Cache hit rate. A sudden drop usually means a wave of new contacts, which is expected. A slow decline means your traffic mix changed.

• Match rate by entry point. If form enrichment matches at 90% and chat at 50%, the difference is input quality, not the API. Chat inputs have more typos and more personal addresses.

Handling PII in a Real-Time Path

Real-time enrichment moves personal data through your application on every request, which makes a few things non-negotiable.

Keep the API key server-side. Never ship it to the browser. If you are personalizing in the client, route the call through your own backend.

Store only what the workflow uses. If you route by company size, you do not need to persist a phone number to do it.

Have a lawful basis for EU contacts. For B2B outreach legitimate interest usually applies, but write down the rationale before you need it and be able to honor access and deletion requests.

Set a retention period. Do not cache enriched records forever. Delete when the relationship ends or the prospect opts out.

Databar's Real-Time API

Databar's API gives developers access to 100+ data sources through a single endpoint. Key features for real-time use cases:

• Waterfall enrichment: Queries multiple providers in sequence. The first provider that returns a result wins. Higher coverage, single API call.

• Per-result pricing: No charge when no data is returned.

• REST API + Python SDK: pip install databar for Python, standard REST endpoints from anything else.

• MCP server: Native integration with AI agents and agentic workflows.

• No annual contracts: Credit-based. Scale up or down without renegotiating.

Read our API-first enrichment guide for code examples and integration patterns.

Also interesting

• API-First Enrichment: Build Custom Data Workflows

• Best Data Enrichment APIs: Technical Guide for Developers

• Batch Enrichment vs. Real-Time: When to Use Each Strategy

FAQ

What is a real-time data enrichment API?

A real-time enrichment API takes a thin input (email address, domain, or LinkedIn URL) and returns a full profile with company data, contact details, and verification results in milliseconds. It's designed for use cases where you need data instantly, like lead form submissions, live chat, and automated routing.

Can I use multiple enrichment APIs together?

Yes, this is called waterfall enrichment. You call Provider A first. If they don't return a result, you call Provider B, then C. Databar handles this natively. A single waterfall call cascades across the providers you configured, up to ten depending on the waterfall, and stops at the first usable result, so you don't need to build and maintain the chain yourself.

What does real-time enrichment cost?

Per-call pricing ranges from $0.01 to $0.10 depending on the data type and provider. Per-result pricing (you only pay when data is returned) is typically $0.02 to $0.15 per successful enrichment. For a team processing 5,000 inbound leads per month, expect $50 to $300/month depending on the data depth required. On Databar this is priced in credits, not per call: the Build plan is $99 per month for 5,000 credits as of September 2026.

How long does Databar keep my enrichment results?

Task data from headless API, SDK, CLI and MCP runs is stored for 24 hours after completion, then permanently deleted, and the task status returns gone. Retrieve and persist results inside that window. Data written into a Databar table stays in the table.

Does a waterfall slow down a real-time lookup?

It can. A waterfall tries providers in sequence and stops at the first usable result, so its worst case is the sum of every provider it has to try. For latency-sensitive paths, trim the chain to two providers, put the fastest first, and set a hard timeout. Run the long chain later as a backfill on whatever the short one missed.

How do I call the Databar API in real time?

The REST API is at https://api.databar.ai/v1 with your key in an x-apikey header. From Python, the SDK's run_enrichment_sync submits and polls in one call. From an AI agent, the hosted MCP server at https://mcp.databar.ai/mcp exposes the same catalog as tools. There is no Node SDK, so from JavaScript call the REST endpoint directly. Full walkthrough in the Python SDK quickstart.

Am I charged when a real-time lookup returns nothing?

No. Billing is outcome-based, so you only pay when data is successfully returned. In a waterfall, only the provider that actually returned data is charged, not every provider that was tried. A partial record counts as a result and is charged.