All documentation
- All documentation
- Features
- Integrations
- API and MCPGetting startedInterfaces
- Account and settings
Programmatic access to your visibility data
Two interfaces over one credential: a small REST API for reporting, and an MCP server that lets an AI client read your data and run scans directly.
Should I use the REST API or MCP?
Use the REST API for reporting into your own dashboards, and MCP for anything an AI client does or anything that starts work. The REST API is read-only; MCP is not.
| You want to | Use |
|---|---|
| Pull scores and recommendations into a dashboard, warehouse or report | REST API |
| Let Claude, Cursor or another AI client work with your data | MCP server |
| Start scans, generate prompts, or draft content programmatically | MCP server — the REST API is read-only |
Both use the same key and the same scopes, so choosing one does not lock you out of the other.
What is on each API page?
Three pages: authentication, the REST API, and the MCP server.
- Authentication — getting a key, the scope vocabulary, plan requirements, and what each rejection means.
- REST API — the five v1 endpoints, with examples and an honest list of what v1 does not do yet.
- MCP server — endpoint, the 27 tools, cooldowns and idempotency.
Is there a machine-readable spec?
Yes, for the REST API: OpenAPI 3.1 at /openapi.json. The MCP server describes itself — call tools/list and it returns every tool with its JSON Schema, so no separate spec is needed.
What rules apply to both interfaces?
A key sees exactly what its owner sees. Scope is the sites that user owns or collaborates on, enforced by row-level security in the database rather than only in the route handler.
Quotas are the plan's quotas. Anything created through the API counts against the same limits as the UI. This is another door into the same account, not a way around the plan.
Running work spends credits. Read scopes and run scopes are separate for exactly this reason. Grant run: only to a key that is meant to start scans.