Buyer Intent Signals API: What to Check First

A buyer intent signals API returns, for a given person or list of people, a machine-readable indication that they're currently shopping a category, so your campaign logic can branch on it automatically instead of a marketer reading a dashboard and deciding by hand. You send identifiers (an email, a phone number, a name and postal address, or an already-resolved ID); you get back intent attributes attached to a resolved consumer record. Here's the part almost nobody evaluates: the thing that makes an intent API useful or useless is rarely the model behind it. It's the identity resolution underneath, and whether you can call it at the moment the decision is actually being made.

Last updated: September 2026

What an intent API is really doing

Strip away the marketing and an intent API performs two operations in sequence, and both have to succeed.

First it resolves. You hand it a partial identifier, usually an email, sometimes a phone or a postal address, and it figures out which person in its graph that refers to. Second it retrieves. Having decided who this is, it returns what it knows about that person's current category activity.

The second step gets all the attention. Vendors publish model names, talk about signal breadth, quote profile counts. The first step is where the failures actually happen, and most people don't realize it, because those failures are invisible in the response payload: a resolution step that matched the wrong person returns a perfectly well-formed intent object about a stranger. Your code has no way to tell. You'll only find out when the campaign underperforms and you can't explain why. And if you've ever had an intent integration quietly disappoint without a single error in the logs, that's why. Nothing was broken in the sense your monitoring understands.

This is why I'd push anyone evaluating an intent API to interrogate the matching method before the modeling method. Probabilistic matching, inferring that two records are the same person from statistical similarity, produces exactly this failure quietly and at scale. Deterministic matching verifies against multiple identity anchors before asserting a match. Exact Match's graph is deterministic rather than probabilistic, with each match verified against multiple anchors (name, email, phone, address). That's a property of the plumbing, not the intelligence, and it constrains the ceiling on everything built above it.

Little-known, big difference: where you call it decides your architecture

Most teams wire an intent API into a nightly batch job, because that's how they wired every previous data vendor. It's usually the wrong shape for intent.

Intent is a perishable attribute. Enriching your whole database nightly and writing intent scores into CRM fields means every downstream system reads a score that's up to 24 hours old, and worse, the score persists in the field long after the underlying state expired. You've turned a live signal into a stale one by storing it. I've seen this exact pattern produce a CRM full of people flagged "in-market" who bought three weeks ago.

Two better shapes:

Call at decision time. When a lead hits the router, when a visitor lands, when the send job assembles a segment: resolve and check intent right there, act on the answer, don't persist it. The signal is never older than the decision it informed.

Batch, but treat the output as a dated snapshot. If you must run batch (and there are good reasons, chiefly rate limits and cost), write the score with its timestamp and make every consumer of that field respect an expiry. A score without a timestamp is a lie waiting to happen.

Which one you pick is mostly determined by throughput, which brings us to the constraint people discover too late.

Rate limits are a design input, not a footnote

Exact Match's API and MCP access defaults to 30 requests per minute, raisable by custom agreement. That number should shape your integration before you write any code, because it draws a hard line between the two architectures above.

At 30 requests/minute, per-record calls are fine for decision-time lookups (a lead router, a visitor event, a form submission) where you're making tens or low hundreds of calls an hour. They are not fine for enriching a 200,000-row list one record at a time; that's a multi-day job that will spend most of its life sleeping off 429s.

For bulk work the platform documents a different path: resolve_and_enrich_rows, which processes an entire list in a single call using signed upload and download URLs, plus async export jobs with status polling and CRM-specific column templates. That's the shape you want for list-scale work: one call, one file back, mapped for your CRM.

The documented data tools are entity_resolve, entity_enrich, entity_relations, and entity_traits for resolving partial identifiers into full profiles, and trait_search, trait_get, group_entities_by_trait, and calculate_trait_lift for building and scoring segments across the platform's 80,000+ targeting clusters. Intent signals are one of the nine data domains carried on those profiles, alongside demographics, behavior, interests, and financial attributes.

Two things worth flagging rather than glossing over, since agencies and integrators will read this section closely. The public product documentation doesn't publish the exact response shape for an intent lookup, whether it's a boolean, a bucketed tier, or a continuous score, so confirm that directly against the live API reference or your account contact before you write parsing code around an assumed structure. And what the documentation does establish is that access is poll-based: export jobs report status through polling, with no webhook described anywhere for intent-state changes, so build your integration assuming pull, not push.

One more thing the documentation doesn't spell out precisely: whether the 30/minute default is a single ceiling that subaccounts draw down together, or whether each subaccount you create for a client gets its own independent 30/minute. Subaccounts are described as getting "isolated, fair-share" limits under one parent key, wording that leans toward independent allowances without stating the arithmetic outright. If you're an agency sizing an integration across several client subaccounts, get that confirmed in writing rather than assuming either direction.

What to ask a vendor before you integrate

Five questions, in the order I'd ask them:

1. Is matching deterministic or probabilistic, and what anchors verify a match?
2. What does the response tell me about recency: when was this signal observed?
3. What's the rate limit, and is there a bulk path that bypasses it?
4. What's returned when you have no match, and can I distinguish "unknown person" from "known person, no current intent"? Those mean opposite things for campaign logic.
5. Is pricing metered per call? If it is, your architecture is being decided by your invoice rather than your requirements.

On that last point: Exact Match runs one flat Unlimited plan with unlimited credits, no per-seat fees, and no overage, which removes call volume as a design constraint. Pricing is set on a short consultation.

For adjacent reading, purchase intent data covers the signal side, in-market buyer prediction covers the prediction layer, and consumer data api covers the broader API surface.