Skip to main content
abm.dev
3 min read

Canonical fields

One call. One shape. Every time. Send abm.dev a person or a company and get back the same structured object — eighty-nine canonical fields and forty signals — no matter which sources answered. The fields are canonical because they don’t move; your code maps them once.

What “canonical” means

A canonical field is a fixed slot with a fixed meaning. Ten data sources feed the enrichment. They disagree, overlap, and go quiet. The canonical layer is what you read instead. You never parse a provider’s raw payload. You never branch on which source replied. You read a field; the field is always there.

Forty-three of the fields describe a person. Forty-six describe a company. Eighty-nine in total. Alongside them sit forty signals — the readable cues an account-based play runs on.

No per-source shapes. No conditional parsing. No surprises in production.

Three things travel with every value

A field is never a bare string. Each value carries its own provenance:

  • source — which provider supplied it. One of ten.
  • confidence — a score from 0 to 1. Higher means more of the sources agree.
  • selection_reason — why that value was chosen. You see the reasoning behind the value before you act on it.

Read the confidence. Read the selection_reason. Decide. A name several sources agree on is not the same fact as a title one source guessed at — and the response tells you which is which.

Confidence runs 0 to 1. There are no bands, no pass marks, no hidden cutoff. It is a continuous score, and you choose the line that fits your play. See Confidence scores for how it is computed.

abm.dev does not fill gaps to look complete. A value is cited or it is not returned. No silent fallbacks. No invented facts.

How the fields are organised

The fields group by intent — identity, contact, company context, scale, the data-quality metadata above, and enriched, source-backed content. The grouping is for your eyes; the contract is the field set. The authoritative, current list of every field and its type lives in the API reference, not in this page.

Field names are versioned

The exact field names and their order are versioned with the API. Read them from the enrichment API reference rather than copying them from prose.

Getting the fields

One request returns them.

Bash
curl -X POST https://api.abm.dev/api/v2/enrichments \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"targets":[{"type":"person","email":"[email protected]"}]}'

Each target also takes a LinkedIn URL or a company domain — point abm.dev at whatever you hold, and it resolves the rest.

Note

Send your key as either x-api-key (used above) or Authorization: Bearer on POST /api/v2/enrichments. Confirm against the live API reference.

Retrieve a finished enrichment by id:

Bash
curl https://api.abm.dev/api/v2/enrichments/{id} \
  -H "x-api-key: YOUR_API_KEY"

For agent loops, results can stream in real time over SSE. Batch jobs fire a webhook when they finish. See Jobs.

Why one shape matters

The whole point is the absence of work. Ten sources go in. One object comes out — the same object every time, every field annotated with where it came from, how sure abm.dev is, and why it was chosen. Map it once. Trust it forever.

Account-based marketing for AI agents. The fields are the contract.

Where to go next