One authenticated GET, and any stack has a blog

The feed is incremental, not a snapshot. GET /v1/publish/{site}/articles?limit=50 returns a list of articles and a next_since cursor, ordered oldest change first by updated_at then id, so two calls for the same page return the same rows rather than whatever the query planner chose that time.

The limit defaults to 50 and is clamped between 1 and 200. Store next_since, send it back as ?since= on the next poll, and the server returns only rows whose updated_at is later than the cursor. When nothing has changed you get an empty list and your own cursor back, so an idle poll costs one cheap request.

A page is widened rather than cut when several rows share an updated_at to the microsecond. Cutting inside a tied group would skip those rows forever once the cursor moved past them.

Articles with status scheduled are excluded. One waiting for its drip publishing slot is written and stored but is not live, so the single-article route 404s for it too.

The same feed carries removals. A retracted article comes back with status unpublished and, where one was recorded, a takedown_reason. Act on it: delete the page or return 410, and drop the URL from anything you generate.

Trust the status field on the record in front of you. It is stamped from the live row at the moment you fetch it, so a retraction reaches you as unpublished even though that article was stored as published on the day it first shipped. Read the field, rather than assuming a feed only ever adds and updates.

When a takedown is a consolidation rather than an editorial removal, the engine records a 301 from the retired path to the surviving one. Read the map from /{site}/redirects and serve it, so the old URL keeps its ranking signal instead of dead-ending.

Filter tombstones out of what you display; act on them when you sync. Those are two different code paths, and conflating them is the usual bug.

Every record carries a schema_version and is built so you never have to generate the SEO furniture yourself.

• Body — body_html rendered and ready, plus body_markdown, excerpt, toc, word_count and reading_time_min.
• Meta — title, meta_description, slug, canonical_path, robots, hreflang, text direction, and complete og and twitter blocks.
• Schema — jsonld, authored by the engine and authoritative. Inject it verbatim rather than rebuilding it; see JSON-LD.
• Media — hero_image, cover_image and an images array, each entry carrying alt text.
• Blocks — an faq array of question and answer pairs, stripped out of the body so you cannot render them twice, plus internal_links, outbound_citations and recommended_products.
• Provenance — author, version, content_hash and first_party_grounded.

content_hash answers the question "did anything actually change?" between versions, which is what lets you skip a rebuild when a republish touched nothing. first_party_grounded tells you whether that article drew on your own product data rather than public sources.

Articles are one endpoint of several, and the same bearer opens all of them.

• /{site}/sitemap.xml and /{site}/rss.xml — generated feeds you can proxy straight through.
• /{site}/llms.txt — the AI-crawler manifest; see llms.txt.
• /{site}/robots.txt — your robots policy, including the single toggle that flips GPTBot, ClaudeBot, PerplexityBot, Google-Extended and CCBot between allow and disallow.
• /{site}/config — verification tags, analytics IDs, Open Graph defaults, locale and sitemap tuning, edited in the dashboard and applied by your site at request time with no redeploy.
• /{site}/redirects and /{site}/clusters — the 301 map, and the topic-cluster graph behind the internal links in your articles.
• /{site}/indexnow-key — serve this value at /<key>.txt on your origin so IndexNow pings verify against a file you host.

Proxying these is usually less work than generating them, and your sitemap then agrees with your feed by construction rather than by discipline.

One thing to check when you compare tools: an API is not always included in the price. Surfer's own integrations page states that its official API is “only available to active users with the API add-on or users on an Enterprise plan” (surferseo.com/integrations, checked 4 September 2026). Here the pull feed is how articles reach a site at all, so every registered site is issued a key and there is nothing to add on.

Polling is the default and asks nothing of your infrastructure beyond an outbound request on a schedule. If you would rather not poll, register a push URL and a push secret, and the engine POSTs each publish, update and takedown to you as an event and an article.

Verify before you trust. X-Thoth-Signature is a hex HMAC-SHA256 of the exact request bytes, keyed by your secret. Recompute it over the raw body, compare in constant time, and read the event name from X-Thoth-Event. Delivery is at-least-once with exponential backoff and a dead-letter entry once the retry budget is spent, so make your handler idempotent on slug and version. The mechanics are set out under webhooks.

Nothing stops you doing both. Take the push as a nudge for instant updates, and run a nightly cursor pass to reconcile anything a failed delivery missed. The endpoint reference is in the docs.

By the time an article is in your feed it has been through the whole pipeline. Topics come from measured demand: DataForSEO plus your own Search Console queries. Research reads the ranking pages, forums and, where it exists, your first-party data — product records, datasheets, support answers. A Claude model writes it. Then four checks run, none of them by the model that wrote it and each including at least one model from a different vendor: fact-check and novelty against the competing pages led by Gemini and GPT, plus an E-E-A-T critique and AI-tell detection, with up to three revision rounds. The model that writes is never the model that checks; that is cross-model validation.

Stated as measured, not promised: across 186 Standard-tier runs, 21% of drafts cleared every check on the first attempt with no revision, and 51% got there within the three revisions allowed; the rest never published. Pro-tier judges are stricter: 25% cleared every check across a small sample of 16 runs.

You pay per published article from a prepaid balance, with no subscription; a draft that fails the checks is not charged. Tiers are on pricing.

The feed suits most stacks. Where it does not:

• You need changes live in seconds. A poll has a floor equal to its interval. Register a push URL and take the signed webhook, keeping a slower poll as the reconciler.
• You cannot store a secret server-side. The bearer key must never reach a browser. A purely client-rendered app has nowhere safe for it, and per-site isolation depends on that key staying private.
• You run WordPress. Use the plugin. It already implements the cursor, the tombstones, the media side-load and the Yoast and Rank Math mapping, and rewriting that in a theme's functions file is a bad afternoon.
• You want a hosted blog rather than a feed. This is a data contract: you render the HTML, own the routes and serve the pages. Nothing here hosts anything for you, by design — the articles must live on your domain to be worth having.
• You expect stock-level or real-time data. The feed carries finished articles and their metadata. It is not a product API, and an article's recommendations are only as current as its last refresh.

Two behaviours to design around rather than discover: a paused site keeps serving everything it has already published, and an article waiting for its drip slot is excluded from the feed and 404s on the single-article route, because to your site it does not exist yet.