Skip to main content
abm.dev
← Notes from the data layer

LinkedIn enrichment API

LinkedIn enrichment API

Stuart McLeod5 min

A great rep once knew every account. Now your agents do.

Here's the call your agent makes:

curl -X POST https://api.abm.dev/v1/enrich/contact \
  -H "Authorization: Bearer $ABM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"linkedin_url": "https://linkedin.com/in/example"}'

Back comes work history, current title, company headcount, verified email, seniority signal, and the confidence score on every field. One call. No scraper to maintain. No silent fallbacks.

That's the promise. The rest of this post is about what's actually inside it — and why the output format matters as much as the data itself.

What does a LinkedIn enrichment API actually return?

Most coverage comparisons focus on hit rate. That's the wrong question for agents.

An agent acting on bad data at machine speed doesn't pause to sanity-check. It sequences, it personalizes, it triggers sends. If the seniority field is wrong, the personalization is wrong — across every account in the run, before a human notices.

So the real question is: what does the response look like, and can you trust each field independently?

A raw LinkedIn profile endpoint — like the one documented at connectsafely.ai — returns work history, education, skills, certifications, and contact info from a single REST call. That's the foundation. But the response is only as useful as its structure. A flat JSON blob with no provenance is fine for a human analyst who can eyeball anomalies. It's a liability inside an autonomous loop.

Here's what agent-ready enrichment output needs:

  • Canonical field names — consistent across providers, so your prompt templates don't break when the upstream source changes
  • Confidence scores per field — not a single match-quality number for the whole record, but a score on current_title, email, company_domain individually
  • Source citations — which provider returned this value, so you can audit a bad personalization after the fact
  • Freshness timestamps — when was this field last verified, not when was the record created

Without those four things, you're not enriching for agents. You're enriching for dashboards.

Why does B2B LinkedIn data decay so fast?

Evaboot, which processes LinkedIn and Sales Navigator URLs at scale, puts it plainly: B2B data decays fast — 22.5% of exported leads are outdated by the time they reach a workflow. People change jobs. Titles shift. Companies get acquired. A record that was accurate in Q1 is noise by Q3.

For a human running a quarterly campaign, that's annoying. For an agent running continuous outbound, it's structural — the agent will keep acting on stale data until something in the loop catches it.

This is why freshness isn't a nice-to-have. It's a correctness requirement. An enrichment API that returns a last_verified timestamp on each field lets the agent decide: is this fresh enough to personalize on, or does it need a re-fetch before it writes the message?

The Enrich.so LinkedIn profile endpoint demonstrates what a clean, queryable enrichment call looks like at the API level — a URL in, structured profile data out, ready to pipe into a downstream step. The interface is simple. The discipline is in what you do with the response.

What does stitching multiple enrichment tools actually cost?

Most growth engineers don't use one LinkedIn enrichment API. They use several — because no single provider has complete coverage, and because different providers are stronger on different signal types. LinkedIn profile data from one source, verified email from another, company technographics from a third.

The result: multiple API keys, multiple billing relationships, multiple response schemas to normalize, and multiple places where a field name collision silently corrupts a downstream record. When the agent hallucinates a prospect's title, you spend an afternoon tracing which provider returned the bad value — if you can trace it at all.

Hunter’s Lead Enrichment API illustrates the category: hand it an email or a professional-profile handle and it returns a full contact record with verification built in. Useful capabilities. But each single-purpose tool you add is another schema to reconcile, another failure mode to handle, another bill to justify at the end of the month.

The alternative is a single enrichment layer that aggregates across providers, deduplicates conflicting values, and returns one canonical record with citations showing which source contributed each field. One call. Ten providers behind it. No per-source bills. No schema gymnastics.

That's the architecture abm.dev's Enrichment API is built on — eighty-nine canonical fields, normalized across providers, with confidence scores and source attribution on every value. Built for autonomous agent loops, not human dashboard-watching.

What does agent-ready actually mean in practice?

The phrase gets used loosely. Here's a concrete definition.

An enrichment API is agent-ready when:

  1. The response is deterministic. Same input, same field names, same schema — regardless of which upstream provider answered. The agent's prompt template doesn't need a conditional branch for "what if this field is called job_title vs current_role."

  2. Failures are explicit. If a field can't be verified, the response says so. No fabricated facts. No silent fallbacks. The agent can handle a null; it can't handle a confident wrong answer.

  3. Citations are machine-readable. Every field carries a source reference the agent can include in its reasoning trace. When a personalization goes wrong, you can pull the audit log and see exactly what the agent believed and why.

  4. The API is callable from an agent loop without rate-limit surprises. Predictable throttling behavior, clear retry semantics, and webhook support for async enrichment on large batches.

Most LinkedIn enrichment APIs were designed for humans exporting CSVs. The interface is fine. The output format is the problem. Agent-first design means the response schema is the product, not an afterthought.

Who is this for?

If you're a founder or growth engineer building an AI-agent go-to-market motion, you're probably already enriching contacts somewhere in the loop. The question is whether the enrichment output is structured for the agent or for a human to review.

If you're a Head of Marketing or RevOps lead watching personalization quality degrade as volume scales, the issue is usually data provenance — the agent is personalizing on fields it can't verify, and there's no audit trail when it goes wrong.

Abm.dev's Enrichment API is built for both. The REST interface is simple enough to call from any agent framework. The response schema is strict enough to trust inside an autonomous loop. And the enrichment MCP server gives you a tool-call interface if your agent is running on an MCP-compatible runtime.

Personalization, at scale.

Once upon a time, a great rep knew which accounts were in budget cycle, which titles actually controlled the decision, and which detail in a prospect's LinkedIn history was worth mentioning. That knowledge took years to build and didn't scale past one person's memory.

The data exists now to do it again — at scale, in every account, on every send. The missing piece was always a data layer the agent could call and trust.

That's what abm.dev is.

Try abm.dev — the account-based marketing API for AI agents. The playground is free. Launch credits with the code LAUNCHCODES.

Stuart McLeod · Co-founder, abm.dev