Skip to main content
Surfaced does not try to be your CMS. Where you already publish somewhere, there are three ways to connect it.

The API

The public API covers the whole content surface: briefs, articles with their blocks and revisions, the fact-check, and publish or unpublish on the hosted blog. The usual shape of a CMS integration is to list articles that have passed their checks, pull the blocks, map them to your own content model, and record the published URL back.
Block bodies are omitted by default because they make responses large. Ask for them only when you need the text.

Webhooks

Rather than polling, register a webhook and be told when something happens: a page published, unpublished, archived, or found to need changes. Register them at /webhooks through the API. There is no interface for this, and the deliveries are signed so you can verify they came from us. Webhooks are the right choice for anything that takes minutes. Generation runs take eight to fifteen minutes per language and audits take several, so polling them wastes your rate limit for no benefit.
A publish that happens through an external integration rather than the hosted blog does not raise the published event. If your pipeline depends on that signal, publish through the blog or the API.

Direct integrations

A Shopify integration exists. Connect by OAuth and publish an article as a Shopify page or blog post, as a draft or live. It is a limited pilot, enabled per workspace, and appears under settings → Integrations only where it has been turned on. There is no WordPress, Webflow or Ghost integration. For those, use the API.

Reading data out

The same API serves the measurement side (analytics, prompts, sources, competitors, the audit report), which is what you want for a dashboard that puts AI visibility beside your other channels. For ad-hoc questions there is also an MCP server, so an AI assistant can query your workspace directly with the same key and the same permissions. For a periodic report, the analytics endpoints plus a scheduled job is usually less work than maintaining a copy of the data.

What not to build

Do not reimplement the metrics. Pulling raw rows and computing your own visibility figure produces a number that disagrees with the app for reasons nobody will be able to reconstruct six months later. Take the computed figures from /analytics/summary. Do not poll a job every second. Use the webhook, or poll with a sensible interval. Generation takes minutes, not seconds.