B2B Enrichment API: The Complete Developer Guide

Building a SaaS tool, an internal CRM, or an automated prospecting pipeline — and need to enrich contact or company data in real time? A B2B enrichment API is probably the missing piece. But between dozens of providers, integration technicalities, and GDPR constraints, it’s hard to know where to start.

This guide covers exactly how B2B enrichment APIs work, how to integrate them cleanly into your stack, and which pitfalls to avoid — whether you’re a back-end developer, tech lead, or growth engineer.

Enrich your B2B data without an API

Derrick enriches your leads directly in Google Sheets — emails, phone numbers, company info — with zero technical setup.

Try for free →

What Is a B2B Enrichment API?

A B2B data enrichment API is a web service that takes a partial identifier as input — an email address, a domain name, a LinkedIn profile URL, a company name — and returns a structured dataset about the corresponding contact or organization.

In practice, you send an HTTP request like this:

GET /v1/enrich/person?email=sarah.johnson@acme.com
Authorization: Bearer YOUR_API_KEY

And you get back a JSON object containing the full name, job title, company, direct phone number, team size, technologies in use, and often much more.

B2B enrichment via API differs from manual enrichment in two fundamental ways: speed (milliseconds vs. hours) and scalability (millions of batch requests vs. a few hundred manually). For a developer building a lead qualification pipeline or an intelligent onboarding system, it’s a core building block.

Now that you have the concept, let’s look at how these APIs work under the hood.

How a B2B Enrichment API Works: Key Concepts

Authentication and API Key Management

Almost every B2B enrichment API uses API key authentication. The mechanism is straightforward: when you sign up, you’re issued a unique key that must be included in every request, either in the HTTP header or as a URL parameter.

The most common standard is the Authorization header with the Bearer scheme:

Authorization: Bearer sk_live_xxxxxxxxxxxxx

Some providers use a custom header like X-API-Key. Either way, never expose this key client-side — keep it in your server-side environment variables.

For more complex integrations (multi-tenant access, delegated OAuth 2.0), some APIs offer short-lived tokens with expiration times. That’s the case for platforms like HubSpot or Salesforce that expose their own enrichment capabilities via OAuth. For the majority of dedicated B2B enrichment APIs, the static key remains the standard.

Core Endpoints of an Enrichment API

Most enrichment APIs expose two fundamental endpoint types:

The bulk endpoint is especially important for CRM enrichment workflows — you send a batch of 100 to 1,000 records in a single request rather than making 1,000 sequential calls.

JSON Response Format

Enrichment APIs consistently return JSON. Structure varies by provider, but here’s a typical response for a contact enrichment:

{
  "status": "found",
  "person": {
    "full_name": "Sarah Johnson",
    "email": "sarah.johnson@acme.com",
    "job_title": "Head of Sales",
    "linkedin_url": "https://linkedin.com/in/sarah-johnson",
    "phone": "+14155551234",
    "company": {
      "name": "Acme Corp",
      "domain": "acme.com",
      "size": "51-200",
      "industry": "SaaS"
    }
  },
  "confidence_score": 0.92
}

The confidence_score field (or match_grade depending on the provider) is critical: it tells you how reliable the match is between your input and the returned profile. A score below 0.7 should be treated with caution — it’s better to leave a field blank than to enrich with incorrect data.

Rate Limiting and Error Codes

Rate limiting is one of the most important technical constraints to plan for before you write your integration. Every B2B enrichment API implements it to prevent abuse and ensure service availability.

Standard behavior: if you exceed your quota, the API returns an HTTP 429 (Too Many Requests) response. Two fields in the response are critical:

• Retry-After: seconds to wait before retrying
• X-RateLimit-Remaining: credits left in the current time window

Here’s how to handle this cleanly in Python:

import requests
import time

def enrich_contact(email, api_key, max_retries=3):
    url = f"https://api.example-enrichment.com/v1/person?email={email}"
    headers = {"Authorization": f"Bearer {api_key}"}
    
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)
        
        if response.status_code == 200:
            return response.json()
        
        if response.status_code == 429:
            # Respect the delay indicated by the API
            wait_time = int(response.headers.get("Retry-After", 5))
            time.sleep(wait_time)
            continue
        
        # Other errors: raise an exception
        response.raise_for_status()
    
    return None  # Failed after max_retries attempts

No-code alternative: if you don’t have dev resources, Zapier and Make handle retry logic and rate limiting natively — no need to write this code yourself.

With these technical mechanics in place, let’s look at what data you can actually retrieve.

Types of Data Returned by an Enrichment API

Contact Data (Person Data)

This is the most common use case for sales and marketing teams. From an email address or LinkedIn URL, an enrichment API can return:

• First name, last name, job title
• Verified professional email
• Direct phone number (mobile or landline)
• LinkedIn profile and social media links
• Geographic location
• Tenure in current role, career history

Contact data quality varies significantly across providers. APIs that pull from fresh sources (real-time LinkedIn, actively maintained databases) consistently outperform those relying on snapshots that are 6 to 18 months old.

Firmographic Data (Company Data)

A company enrichment from a domain typically returns the firmographic attributes you need to qualify an account:

These data points are the foundation of any automated CRM enrichment system — they let you score and segment accounts without manual intervention.

Technographic Data (Tech Stack)

Some specialized APIs expose a tech lookup endpoint: give them a company domain, and they return the technologies detected on its website (CRM, analytics, marketing automation, front-end framework, etc.). This is powerful qualification data for SaaS vendors targeting companies based on their existing stack.

Now that you know what you can retrieve, here’s how to actually integrate it.

How to Integrate a B2B Enrichment API: Step-by-Step Guide

Step 1: Define Your Enrichment Strategy

Before writing a single line of code, nail down your strategy:

• Real-time enrichment: triggered by an event (new CRM lead, form submission). Best for low volumes where latency matters.
• Batch enrichment: scheduled processing on an existing list. Best for high volumes where latency doesn’t matter.
• Hybrid: real-time for new records, batch to refresh stale data on existing ones.

Expected result: a clear architecture diagram before you start building.

Step 2: Authenticate and Test Your First Call

Grab your API key from the provider dashboard and run a quick test with curl:

# Test company enrichment by domain
curl -X GET "https://api.example.com/v1/company?domain=acme.com" \
  -H "Authorization: Bearer sk_live_your_api_key" \
  -H "Accept: application/json"

If you get an HTTP 200 with structured JSON back, authentication is working.

Expected result: a valid JSON response with the test company’s data.

Step 3: Parse and Map the Response

The raw API response needs to be transformed to match your application’s data schema. Here’s a Python example with basic validation:

def parse_company_enrichment(api_response: dict) -> dict:
    company = api_response.get("company", {})
    
    return {
        "name": company.get("name"),
        "employees": company.get("employee_count"),
        "industry": company.get("industry"),
        # Default value if the field is missing
        "country": company.get("country", "Unknown"),
    }

Expected result: a clean object ready to be inserted into your database or CRM.

Step 4: Implement Caching to Optimize Credit Usage

A domain doesn’t change every hour. Caching enrichment responses avoids burning credits on the same data twice. Rule of thumb: a TTL (time-to-live) of 30 days works well for firmographic data; 7 days for contact data, since job titles change more frequently.

Expected result: your API credit consumption drops by 40–60% on bulk enrichment runs.

Step 5: Set Up Error Handling and Monitoring

Your integration needs to anticipate three common failure scenarios:

• Profile not found (HTTP 404 or "status": "not_found"): log the status without crashing the workflow
• Rate limit hit (HTTP 429): implement exponential backoff
• Server error (HTTP 5xx): retry with delay, alert if persistent

Expected result: a robust pipeline that doesn’t break on a single failed enrichment.

Real-World Use Cases for a B2B Enrichment API

Form Auto-Population

Mike, a developer at a SaaS startup, integrates an enrichment API into the signup form. When a prospect enters their work email, the API instantly returns their company name, size, and industry — fields are pre-filled automatically. Result: form completion rate increases by 35%, and CRM data is immediately usable without any manual input.

Automated CRM Enrichment

Emma, a Sales Ops manager at a scale-up, triggers a batch enrichment via API every time leads are imported into HubSpot. The API fills in missing fields — company size, industry, direct phone — without her SDR team needing to do manual research. According to HubSpot, sales teams spend an average of 27% of their time on data-related tasks that automation can eliminate.

Real-Time Lead Scoring

Mark, a Growth Engineer, uses an enrichment API as a component of his scoring engine. As soon as a lead enters the pipeline, the API returns the firmographic data needed to calculate an ICP (Ideal Customer Profile) score — the startup automatically qualifies leads before the sales team even sees them.

These are powerful workflows — but they come with legal obligations you can’t ignore.

GDPR and Compliance for Enriched Data

Using a B2B enrichment API means processing personal data (emails, names, phone numbers). In the European Union, GDPR applies in full — even when the data comes from a third-party provider.

Three obligations to know:

1. Legal basis. In B2B, the most commonly invoked legal basis is legitimate interest — prospecting professionals within the context of their work. This must be documented in your Records of Processing Activities (RoPA) and must pass the balancing test.

2. Purpose limitation and data minimization. You can only enrich the data necessary for your declared purpose. If your goal is B2B prospecting, you don’t need to store personal data unrelated to the professional context.

3. Right to object. Any person whose profile you’ve enriched can object to the processing. Your infrastructure must be able to identify and delete that data on request.

On the provider side, always verify that the API provider is itself GDPR-compliant and has a Data Processing Agreement (DPA) available. Reputable providers publish it in their documentation or provide it on request.

For teams operating in the UK, the ICO (Information Commissioner’s Office) framework applies similar principles to GDPR post-Brexit.

No-Code Alternative: Enriching Without an API Using Zapier, Make, and Derrick

Building and maintaining an API integration takes time and dev resources. For teams without an available developer — or those who just want to move fast — there’s a no-code approach that delivers equivalent results.

Derrick is a B2B enrichment tool native to Google Sheets that connects directly to Zapier, Make, and n8n. You can build the same enrichment pipeline as with a REST API, without writing a line of code:

• New lead enters HubSpot → Zapier triggers Derrick → Derrick enriches with email, phone, company data → results pushed back to your CRM
• LinkedIn list imported to Google Sheets → Derrick enriches 50+ attributes in bulk → export to your pipeline

For an SDR or Growth Marketer who wants to enrich LinkedIn leads with professional emails and phone numbers, Derrick via Google Sheets is often faster to set up than a classic API integration — and requires zero development skills.

Common Mistakes and How to Fix Them

Problem 1: Enriching Without Checking the Confidence Score

Impact: Incorrect data accumulates in your CRM, corrupting your campaigns and skewing your lead scoring.

Solution: Always filter responses where confidence_score falls below a defined threshold (typically 0.7 to 0.8). Store the score alongside the data to allow future review.

Problem 2: Ignoring Rate Limiting Until the First 429

Impact: Your pipeline crashes in production, enrichments are dropped, the sales team can’t understand why data is missing.

Solution: Implement exponential backoff from day one (see Step 5 above). Monitor the X-RateLimit-Remaining header continuously to stay ahead of limits.

Problem 3: Not Caching Responses

Impact: Unnecessary credit consumption on already-enriched domains. At scale, this can double your bill.

Solution: Store each enrichment response with a timestamp and TTL. Before any API request, check if the data is cached and still valid.

Problem 4: Choosing a Provider Without Checking Data Freshness

Impact: High match rate on paper, but stale data in practice — changed job titles, invalid emails, closed companies.

Solution: Request a test dataset before committing. Run it against 100–200 contacts whose current data you already know — it’s the only reliable way to measure actual data quality.

Problem 5: No Signed DPA With the API Provider

Impact: Potential GDPR violation. You’re responsible for data processing even when the data originates from a third party.

Solution: Sign a Data Processing Agreement (DPA) with every API provider that processes personal data on your behalf. Non-negotiable if you operate in the EU or UK.

Key Takeaways

• A B2B enrichment API uses REST architecture: API key authentication, dedicated endpoints (person, company, bulk), structured JSON responses.
• The confidence_score is your safeguard against bad data — never ignore it.
• Rate limiting is unavoidable: implement exponential backoff and monitor X-RateLimit-Remaining from day one.
• Caching is mandatory at scale: a 30-day TTL on firmographic data cuts your credit consumption in half.
• GDPR applies to your enrichment workflows: documented legal basis, data minimization, signed DPA with your API provider.
• No dev resources? Derrick + Zapier/Make delivers the same results without any code.

Conclusion: Where to Start Your Integration

A well-integrated B2B enrichment API transforms your data pipeline: leads qualify automatically, your CRM stays current, and your sales team prospects with fresh data instead of spending time hunting for it. The technical concepts — authentication, rate limiting, error handling, caching — aren’t difficult to master, but they need to be planned from the start.

If you have dev resources, the 5 steps in this guide give you the complete roadmap. If you’d rather move fast without code, Derrick connected to your stack via Zapier or Make gives you access to the same enrichment data in minutes.

Enrich your leads without writing a single line of code

Connect Derrick to your CRM via Zapier or Make and automate contact enrichment in minutes.

Try for free →

FAQ

What is a B2B enrichment API? It’s a web service that automatically completes contact or company data from an input identifier (email, domain, LinkedIn URL). It returns JSON via authenticated REST requests and allows you to enrich leads at scale without any manual effort.

What’s the difference between real-time and batch enrichment? Real-time enrichment triggers an API request when an event occurs (new lead, form submission) — latency of a few milliseconds. Batch enrichment processes a complete list in a single scheduled operation — ideal for large volumes and refreshing existing records.

How do you handle rate limiting in an enrichment API? Monitor the X-RateLimit-Remaining header in every response. On HTTP 429, implement exponential backoff and respect the Retry-After header value. For high volumes, prefer bulk endpoints that consume fewer API calls per record.

Does GDPR apply to API-based enrichment? Yes. Even when data comes from a third-party provider, you’re responsible for the processing. You need a documented legal basis (usually legitimate interest in B2B), a signed DPA with your provider, and the ability to respond to opt-out or deletion requests.

Can you enrich B2B data without an API? Yes. Tools like Derrick work natively in Google Sheets and integrate with Zapier, Make, and n8n. You build the same enrichment workflow as with a REST API — without writing code — by connecting your lead sources to your CRM in a few clicks.