The SeoMap REST API for Agencies and Developers
What actually gets automated
Reading scan results out of a dashboard by hand is fine for a handful of clients. It stops being fine the moment someone wants that data somewhere else — a client-facing dashboard, an internal spreadsheet that refreshes itself, a Zapier or n8n workflow that posts a Slack message when a keyword’s SoLV drops. Every one of those needs the same thing: a way to pull SeoMap’s own data out programmatically instead of copying it by hand. That’s what the REST API is for, and nothing more — it’s a read path, not a way to drive the product remotely.
What’s actually in it
Four endpoints, all GET, all JSON: a list of an account’s projects, the scans for a given project, the detail of one scan, and the individual grid points behind a scan — rank, status and coordinates for every point that was measured. That last one matters more than it sounds: it’s the same per-point data the heatmap itself renders, available as plain rows instead of pixels, which is what makes a custom visualization or a client-specific report format possible without reimplementing a scan.
Authentication is a bearer token — a key generated and revoked from Settings, shown once at creation the same way any sane API key UI works. Every response is scoped to the key’s own owner; asking for a project that belongs to someone else returns a plain “not found,” not an error that confirms the ID exists but you can’t see it. Internal numbers — cost, credits charged, BYOK status — deliberately don’t come back through the API, the same billing-data boundary the public share links already draw.
Who this is actually for
Two groups get real, immediate use out of this. Agencies running SeoMap for a roster of clients can pull ARP/ATRP/SoLV straight into whatever reporting stack they already run for clients, instead of asking clients to check a separate tool — one data source, wherever the agency’s actual reporting already lives. Developers and technically-minded freelancers get the more direct win: wiring SeoMap into Zapier, n8n or Make’s generic HTTP modules takes an API key and a few minutes, not a native integration that has to exist first. A dropped rank at a specific point, a completed scheduled scan — either can trigger a webhook workflow the moment the data is there, without polling a dashboard to notice it happened.
What it deliberately doesn’t do
It’s worth being precise about the boundary here, because “API” invites assumptions. This is read-only — there’s no endpoint to start a scan, create a project, or change a schedule; that combination pairs naturally with recurring scans doing the actual triggering on their own clock, with the API used purely to pull whatever they produced. There’s also no bulk export endpoint beyond what the four resources already return — for a one-off full CSV of a scan’s points, the built-in export button on the scan itself is still the faster path than scripting a pull.
The takeaway
The API isn’t a new feature to learn — it’s the same data every SeoMap user already sees in the app, made available as plain HTTP instead of locked to the dashboard. For an agency piping numbers into its own reporting, or a developer wiring rank changes into an existing automation stack, that’s the entire point: get SeoMap’s numbers to wherever they’re actually needed, without asking anyone to check one more tab.