Home/Offers/Sales, Marketing & Ad Tech/Buying Intent Intelligence API

Sales, Marketing & Ad Tech

Buying Intent Intelligence API

Intent data has a credibility problem, and it is deserved. Most of what is sold as intent is a weak proxy wrapped in a confident number.

Sales intelligence platforms
ABM software
Marketing automation vendors
Demand generation agencies

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

The pitch is appealing: know which accounts are in-market before they contact you. The usual implementation is less appealing. A co-op of publishers reports anonymised page views, a vendor maps IP ranges to companies, and the output is a per-account topic score. The IP mapping is noisy and getting noisier as corporate traffic moves to residential and cloud egress. The page views may be one intern reading a blog post. The score has no stated base rate, so a sales team cannot tell an in-market account from a company whose employees happen to read industry news.

Sellers notice. Pipeline built on third-party intent frequently converts no better than a well-built list, which is why the category carries so much scepticism. The failure is not that intent is unknowable — it is that weak signals are being presented with strength they do not have.

What is actually informative tends to be first-party and specific: repeat visits to pricing and comparison pages from a resolved account, a stalled opportunity re-engaging with documentation, a job posting naming the category or a competitor's product, a technology change that creates a need, a publicly announced project. These are fewer, slower and far more predictive than aggregate topic scores. A system worth building returns them individually, with their basis, and reports measured lift against a control instead of asserting it.

Who buys this

Sales intelligence platforms, ABM software, Marketing automation vendors, Demand generation agencies

Category: Sales, Marketing & Ad Tech

What the API returns

What comes back

Account-level signals listed individually, each with type, date, strength and basis
First-party web and product signals resolved to an account where resolution is confident
Hiring signals: postings naming the category, competing products or relevant roles
Technology change signals where the source permits commercial use
Publicly announced initiatives, funding and expansion that create a budget occasion
Signal decay, so a four-month-old page view is not weighted like yesterday's
A composite score that is optional, calibrated, and reported with its base rate
Measured lift against a holdout, published as a standing output rather than a claim

Endpoints

Method	Path	Returns
GET	/v1/accounts/{id}/signals	Signals for one account with basis and strength
POST	/v1/accounts/batch	Signals across an account list
GET	/v1/signals/stream	Recent signals across your tracked accounts
POST	/v1/first-party/ingest	Your own web and product events for account resolution
GET	/v1/accounts/{id}/score	Optional composite score with base rate and calibration
GET	/v1/evaluation/lift	Measured lift against a holdout cohort

Request and response

illustrative

Request

{
  "account_ids": ["cmp_0441209"],
  "categories": ["data_integration"],
  "window_days": 90,
  "include_score": true,
  "min_signal_strength": "moderate"
}

Response

{
  "account_id": "cmp_0441209",
  "window_days": 90,
  "signals": [
    {
      "type": "first_party_pricing_visits",
      "date": "2026-10-20",
      "strength": "strong",
      "basis": "4 sessions, 3 distinct resolved users, pricing and comparison pages",
      "source": "your_own_site",
      "consent_basis": "site_visitor_notice_and_cookie_consent"
    },
    {
      "type": "job_posting_mentions_category",
      "date": "2026-10-09",
      "strength": "moderate",
      "basis": "Posting for a data platform engineer naming two competing products",
      "source": "public_careers_page"
    },
    {
      "type": "third_party_topic_activity",
      "date": "2026-10-02",
      "strength": "weak",
      "basis": "Aggregate publisher co-op activity, company-level IP attribution",
      "caveat": "IP-to-company attribution is unreliable; treat as weak context only"
    }
  ],
  "score": { "value": 64, "base_rate_in_cohort": 0.07, "lift_vs_cohort": 2.4,
             "calibration": "measured on 2026 Q2-Q3 holdout" },
  "personal_data": "No individual-level identifiers returned. Account-level aggregation only."
}

Where the data comes from

Your first-party web and product events	Visits, documentation reads and trial activity from your own properties under your own consent notices — the strongest signal available and the one you already own
Public job postings	Openly published careers pages, subject to each site's terms; postings naming a category or a competitor are among the more honest signals in this field
Company announcements and filings	Publicly disclosed projects, funding and expansion that create a budget occasion
Licensed third-party intent co-ops	Available commercially; we include them with their weakness labelled rather than blended invisibly into a score
Technology detection sources	Only where terms permit commercial use of derived data; several widely-used sources do not
Your own closed-won and closed-lost outcomes	Required for calibration — without outcome data a lift figure cannot be measured and should not be quoted

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Signals kept separate and individually attributed; the composite score is derived from them, never a replacement for them
Account resolution for first-party events using authenticated identity and form data in preference to IP, with unresolved traffic left unresolved
Explicit strength labels fitted against your own conversion outcomes, so 'strong' means measurably strong in your funnel rather than in a vendor's marketing
Base rate reported alongside every score, because a score without a base rate cannot be acted on rationally
Decay functions per signal type, calibrated from how predictive each type remains over time
Holdout evaluation as a permanent part of the service: a cohort is deliberately not worked, and lift is measured against it
Aggregation thresholds so no output is attributable to an identifiable individual
Honest suppression: where a category has too little signal to beat the base rate, the API says so instead of returning a number

What it changes for the business

Fewer, better-founded plays

Separating strong first-party signals from weak aggregate ones changes which accounts get worked.

Scores that can be acted on

A score with its base rate and measured lift attached can be put into a threshold decision; one without cannot.

Defensible data practice

Account-level aggregation and documented lawful basis survive a procurement security review and a DPA negotiation.

Honest internal reporting

A standing holdout means the intent layer's contribution to pipeline is measured rather than claimed.

How it fits into your product

How it embeds

First-party event ingestion from your existing analytics or product telemetry
Signal webhooks into sequencing, ABM and workflow tools at the point a signal appears
Account list subscriptions, so only accounts your customers care about are processed
Deployment inside your environment where first-party event data cannot leave it
Per-tenant data separation and documented retention windows for DPA purposes
White-label delivery, with the caveat language on weak signals carried into the output your customers see

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Is third-party intent data actually worth buying?

Often it is not, and we will tell you when the evaluation says so. The common failure modes are real: IP-to-company attribution degrades every year as traffic moves to cloud and residential egress, topic activity conflates research with idle reading, and most vendors cannot show lift against a holdout. We include co-op data where you already license it, label it weak, and let the measured lift decide whether it stays. If first-party signals carry the whole result, the honest recommendation is to stop paying for the rest.

What is the lawful basis for processing this?

It differs per signal and that difference is the design constraint. First-party web events run on your own notices and consent. Public job postings and announcements are published company information. Third-party co-op data depends on the consent collected at the publisher, which you are relying on and cannot personally verify — a genuine risk worth naming in your own DPA. We build with documented basis per source, account-level aggregation, and no individual-level profiles.

Can it tell us which person at the account is researching?

Not from this service. Individual-level intent profiling of people who have not identified themselves to you is where this category gets into real legal and ethical trouble, and we would not build it. Where someone has identified themselves to you — logged in, filled a form, requested a demo — that is your own first-party relationship and your own CRM's business, not an inference we would construct.

How soon can lift be measured?

Usually one to two full sales cycles after launch, because lift needs outcomes and outcomes need time. Until then any figure quoted is a projection. We would rather set the holdout up at launch and have a real number later than present an in-sample estimate early.

What if the signals do not predict anything in our market?

That happens, particularly in categories with long buying cycles and no public footprint. The evaluation harness would show it, and the recommendation would be to stop rather than to retune indefinitely. A build that ends with 'this does not work for your category' is a cheaper outcome than one that ships and quietly misallocates a sales team.

All Sales, Marketing & Ad Tech offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers