Publishing through a webhook

The finished article and everything generated alongside it: title, slug, Markdown and rendered HTML, excerpt, meta description, canonical URL, featured image and alt text, the author entity as a structured object, tags, the intended publication time, and the JSON-LD graphs. The precise field names and nesting are documented in the app, and that is what you should code against rather than any description on a marketing page.

The destination is configured with a signing secret, and deliveries carry a signature computed over the request body. Verify it against the raw bytes you received rather than a re-serialized parse, use a constant-time comparison, and reject requests whose timestamp falls outside a short tolerance window. The exact header names and signing scheme are in the current documentation — implement from there, not from memory.

Yes, and you should design for it. Delivery is at-least-once, so a lost acknowledgement or a timeout on your side produces a retry carrying the same event. Key your write on the stable article identifier and upsert. Approved rewrites also arrive as a fresh delivery for an existing article, so the update path is not an edge case — it is how the improvement loop reaches your site.

Yes, and it is one of the two common receiver shapes. Your endpoint commits a Markdown or MDX file with frontmatter and lets your existing deploy pipeline do the rest. The trade is that publication becomes asynchronous: the article is live when the build finishes, not when the delivery succeeds, and a failing build blocks it. Decouple the commit from the deploy so content is never lost to a broken pipeline.

It does, because nothing between generation and your endpoint modifies it. The graphs are stored on the article record and travel with the event. The risk is entirely on your side: reconstructing schema from your own fields instead of rendering what you were sent, or leaving a layout-level Article graph in place so the page carries two conflicting descriptions of itself.

Through the REST API with a scoped key. The publishing queue records that a delivery succeeded, which is not the same as knowing where the page ended up — on a build-based receiver, the URL does not exist yet at delivery time. If you want permalinks recorded against articles, have your receiver call back once the page is live. The MCP server exposes the same operations if an agent is driving.