Skip to main content
​
APIMCP
Client MCP & API revamp
MCP: sign in instead of pasting a key. The MCP server now supports an OAuth 2.1 login flow (PKCE + Dynamic Client Registration) — connect Claude, Cursor, or another MCP client by signing in and approving access, scoped to exactly the projects and read/write permissions you choose. The sea_ API-key bearer path still works unchanged for scripts and headless clients. See MCP integration.New data coverage, in REST and as MCP tools:
  • Share of Voice & Competitors — brand vs. competitor mention-share ranking, its daily trend, and the full tracked-competitor roster
  • AI Traffic — first-party AI-crawler visits and AI-referral sessions, sourced from the tracker/CDN pipeline
  • Shopping visibility — AI shopping/product-carousel appearances
  • Prompt Answers — raw, per-response AI-answer data (text, mentions, citations) for a single prompt
  • GET /reports — list previously generated shareable reports for a project
Write actions over MCP — generate_report, trigger_audit, and refresh_sitemap are now callable as MCP tools (in addition to their existing REST POST endpoints), each gated on the write scope and an explicit confirmation.Hardened REST responses. Every response now carries an X-Request-Id and standard rate-limit headers (600 requests/minute per API key); errors are RFC 9457 application/problem+json with a stable code field you can branch on. See the new error reference. The POST /reports, POST /audits, and POST /sitemap/refresh endpoints additionally accept an Idempotency-Key header, so a retry after a timeout or dropped connection never triggers the action twice.Clearer “not connected” errors. Google Search Console, Google Analytics 4, and AI Traffic endpoints now return an actionable 409 with a direct link to the right settings page when the integration isn’t connected yet, instead of a generic failure.This page, and the interactive API reference — a full OpenAPI 3.1 spec with a live playground for every endpoint, generated straight from the shipped route contracts.

​
Deprecation policy

  • 12 months’ notice. We give at least 12 months’ notice before removing or changing the behavior of any documented endpoint, parameter, or response field. Adding a new endpoint or an additive response field is not a breaking change and isn’t subject to this notice.
  • Deprecation / Sunset headers. Once an endpoint is scheduled for removal, its responses carry a Deprecation header (the date it was deprecated) and, once a removal date is fixed, a Sunset header (the date it stops working), per the IETF Sunset header convention. Nothing on this API is deprecated today.
  • Versioning posture. /api/mcp/* — despite the name — is the frozen v1 REST contract: stable, versionless-by-default. New capabilities land as new endpoints or new additive fields, never as a breaking change to an existing one. /api/v1/* is reserved for surfaces that need independent versioning from that contract (currently just /api/v1/projects/{projectId}/audits, which mirrors GET /api/mcp/projects/{projectId}/audits exactly).
  • A breaking change, if one is ever required, ships as a new endpoint or a new version prefix, announced here first, with the prior version supported through the full notice window.
Questions about an upcoming change? support@searchable.com.