Home/Offers/Sales, Marketing & Ad Tech/SEO Ranking Intelligence API

Sales, Marketing & Ad Tech

SEO Ranking Intelligence API

Rank tracking looks like a solved problem until you build it. Then you discover there is no single ranking — only a result for a location, a device and a moment.

SEO platforms
Digital agencies
Content marketing software
E-commerce analytics vendors

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

Every marketing platform eventually needs search position data, and most buy it from one of a handful of providers. The data arrives as a number per keyword per day, which is a convenient fiction. Results differ by city, by device, by whether a personalised session is involved, and by which of several result layouts was served. A single integer hides all of that, and the hiding is where client arguments start.

The second problem is that the page is no longer a list of ten links. Local packs, shopping units, featured snippets, video carousels, people-also-ask blocks and AI-generated answers occupy the positions users actually look at. A site ranked third can sit below the fold. Position without layout context describes the wrong thing — what matters is where the result sits relative to everything else on the page.

Then there is collection, which is the genuinely constrained part. Search engines do not offer unrestricted commercial result APIs for this purpose, their terms govern automated querying, and legitimate large-scale collection means working within permitted sources, licensed providers and sensible query budgets. Any vendor quoting unlimited volume at trivial cost is describing something that will either break or create a problem for the buyer.

Who buys this

SEO platforms, Digital agencies, Content marketing software, E-commerce analytics vendors

Category: Sales, Marketing & Ad Tech

What the API returns

What comes back

Position per keyword by location, device and language
Result page composition: which features appeared and where the organic links sat relative to them
Pixel-depth position, so an above-the-fold third place is distinguishable from a below-the-fold third place
Ranking movement with change detection that separates real shifts from result volatility
Competitor positions on the same keyword set, collected in the same query
Feature ownership: who holds the snippet, the local pack places, the shopping units
Keyword volatility scoring, so an unstable query is not reported as a dramatic change
Collection metadata on every data point: when, from which location, which source and under which licence

Endpoints

Method	Path	Returns
POST	/v1/rankings/query	Positions for a keyword set by location and device
GET	/v1/keywords/{id}/history	Historical position series with layout context
GET	/v1/keywords/{id}/serp	Full result page composition for one query
POST	/v1/competitors/compare	Competitor positions across a keyword set
GET	/v1/movements	Significant ranking changes with volatility context
POST	/v1/schedules	Set collection cadence per keyword group

Request and response

illustrative

Request

{
  "keywords": ["industrial flow meter", "flow meter calibration service"],
  "locations": [{ "country": "US", "city": "Columbus, OH" }],
  "device": "mobile",
  "competitors": ["example-industries.com", "northbridge-mfg.com"],
  "include_serp_composition": true
}

Response

{
  "collected_at": "2026-10-22T09:14:00Z",
  "collection_source": "licensed_provider_a",
  "results": [
    {
      "keyword": "industrial flow meter",
      "location": "Columbus, OH, US",
      "device": "mobile",
      "serp_composition": [
        { "position": 1, "type": "ai_answer", "pixel_top": 180 },
        { "position": 2, "type": "shopping_unit", "pixel_top": 640 },
        { "position": 3, "type": "organic", "domain": "northbridge-mfg.com", "pixel_top": 1120 },
        { "position": 4, "type": "people_also_ask", "pixel_top": 1340 },
        { "position": 5, "type": "organic", "domain": "example-industries.com", "pixel_top": 1680 }
      ],
      "tracked_domain": {
        "domain": "example-industries.com",
        "organic_position": 2,
        "absolute_position": 5,
        "pixel_top": 1680,
        "above_fold": false,
        "change_7d": -1,
        "change_significant": false,
        "keyword_volatility": 0.41
      },
      "feature_ownership": { "featured_snippet": null, "ai_answer_cites": ["northbridge-mfg.com"] }
    }
  ]
}

Where the data comes from

Licensed search data providers	Commercial result data under a licence that permits redistribution through your product — the usual foundation, and the licence terms shape what you may resell
Official search engine APIs	Available for some surfaces and some use cases, with quotas and terms that define what is permitted
Your own search console connections	Impressions, clicks and average positions for the customer's own property, which is first-party and authoritative in a way third-party collection is not
Your clients' analytics	Session and conversion data, so position changes can be related to outcomes rather than tracked for their own sake
Location and language reference data	Correct locale, city and language parameters, which is where a surprising share of rank data errors originate
Historical archive	Positions and page layouts are not retrievable retrospectively; the archive has to be captured continuously from the day collection starts

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.

Collection scheduled against a query budget, with cadence per keyword group rather than a uniform daily sweep that wastes most of the budget on stable terms
Layout parsing into a typed component list, so position is reported relative to everything actually on the page
Pixel-depth estimation per device profile, because above-the-fold is a far better predictor of traffic than ordinal position
Volatility estimation per keyword from its own history, used to suppress change alerts on inherently unstable queries
Change-point detection rather than day-over-day deltas, which otherwise generate constant false alarms
Collection metadata attached to every point — source, location, device, timestamp — so a disputed number can be traced
Deduplication and reconciliation where several sources cover the same query, with disagreement surfaced rather than averaged
Monitoring for layout changes on the search side, which break parsers without warning and show up first as an unexplained drop in feature detection

What it changes for the business

Client disputes that end

Location, device and collection metadata on every data point turn an argument about a number into a traceable fact.

Reporting that reflects visibility

Pixel depth and layout context describe whether a result is actually seen, which ordinal position does not.

Collection cost under control

Cadence tuned to keyword volatility concentrates query budget where positions actually move.

Alerts people stop muting

Volatility-aware change detection reduces the false alarms that cause teams to ignore ranking notifications.

How it fits into your product

How it embeds

REST query and history endpoints for your own dashboards and client reports
Scheduled collection with per-group cadence, managed through the API rather than a console
Movement webhooks into client alerting and agency reporting workflows
White-label delivery under your brand, including in exported client reports
Bulk export for agencies running their own warehouses
Per-client entitlements on keyword volume, locations and history depth

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 12 weeks

Discovery and data review

Weeks 1–2

We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.

Architecture and prototype

Weeks 3–4

You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.

Production build

Weeks 5–10

Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.

Integration and handover

Weeks 11–12

We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.

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

Why not just collect the results directly at scale?

Because search engine terms govern automated querying, and designing a product around ignoring them transfers a real risk to you and your customers. Legitimate builds run on licensed providers, official APIs where they exist, and query budgets that respect the sources. That constrains volume and costs money, and we would rather put that constraint in the architecture document than discover it after launch.

Is there a single true ranking for a keyword?

No. There is a result for a location, a device, a language and a moment, and personalisation adds further variation. Anyone reporting one number per keyword per day has picked a default and not told you which. We make the parameters explicit on every data point, which is less tidy and considerably more honest.

Can you reconstruct history before we start?

Only what a licensed provider already holds, and their archive has its own location and cadence choices baked in. Your own archive starts the day collection starts. We normally begin capture during the prototype so history is accumulating while the rest of the build proceeds.

How do you handle AI answers appearing in results?

They are parsed as a result component with their position and pixel extent, and cited domains are extracted where present. Behaviour on these surfaces changes frequently, so detection needs active maintenance. For deeper measurement of brand presence across AI answer surfaces, that is a different problem than rank tracking and we would scope it separately.

What history depth is realistic for client reporting?

As deep as your licence and your archive allow. Licensed providers vary in how much history they will let you redistribute, and some restrict it to recent windows. We confirm the depth you can legally expose to clients during discovery rather than building a three-year chart you are not permitted to show.

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