Your app receives the article — Netlify just deploys it.
Netlify is hosting and deployment, not a CMS: it has no site builder and no content store, so there is nothing inside Netlify for an article to land in. What receives your articles is the app Netlify serves. Add one route handler — or a single Netlify Function if your build is static — and DraftSEO POSTs each finished article to it as signed JSON. Your framework renders the page; Netlify does what it already does and serves it.
| Netlify content API | None — sites, deploys, DNS — api.netlify.com has no post, page or article resource |
|---|---|
| Where articles land | Your framework's receiver — one route handler, recipe provided per stack |
| Security | HMAC-signed + timestamped — verified over ${timestamp}.${rawBody}, 5-minute replay window |
| Fully static builds | Add a runtime first — your SSR adapter, or one Netlify Function as the receiver |
| "Netlify CMS" | Renamed Decap in 2023 — a browser-side Git client, not a publishing API |
Who does what
Pick the framework your site is built in, paste its receiver, verify the signature, and store the post. After the green test delivery: zero minutes per article, and your components, routes and caching stay entirely yours.
Commit it once — Netlify deploys it like any other change.
Setup
The setup is your framework’s, not Netlify’s — so the first step is naming the stack.
Connect a site → Netlify, then choose Next.js, Astro, Nuxt, SvelteKit or Node.js. You land on that stack’s recipe with a signing secret.
~1 minute
SSR, an adapter or a Netlify Function — a webhook needs something answering at request time. A fully static build gets a single function; the Node.js recipe drops straight in.
Usually already true
Verify the HMAC over ${timestamp}.${rawBody}, upsert the post, render it from your own pages. Commit, and Netlify deploys it with your next build.
~10 minutes
DraftSEO fires a signed test at your endpoint — and a deliberately invalid one, which your receiver must reject. Two green checks mean you are connected.
~1 minute
Every generated article arrives at your endpoint on schedule, images and metadata included.
Ongoing · zero clicks
FAQ
No — and no tool does, because there is nothing there to publish into. Netlify’s API manages sites, deploys, files, environment variables, forms, hooks and DNS; it has no post or page resource, and a deploy is an atomic snapshot of your whole site rather than a place to add one article. DraftSEO publishes into the app Netlify serves, which is the part that actually renders your blog.
Yes, with one addition. A webhook needs something running when the request arrives, so either enable your framework’s SSR adapter or add a single Netlify Function as the receiver — the Node.js recipe works there unchanged. Store the post, then either render it server-side or call a build hook to rebuild the static pages.
Netlify CMS was renamed Decap CMS in 2023, and it is a different kind of thing: a React app that runs in the editor’s own browser and commits Markdown to your Git repository. There is no server and no write API for an outside service to call, and Netlify’s Git Gateway — the one path that looked like one — is deprecated in Netlify’s own docs. The webhook route is both supported and better: it never touches your repository, so a bad value can never break a build.
Netlify builds and runs JavaScript and TypeScript apps, and DraftSEO ships idiomatic receiver recipes for Next.js, Astro, Nuxt, SvelteKit and Node/Express. Anything else in Netlify’s framework list — Remix, Gatsby, Angular, Vite, TanStack Start — receives the same signed JSON; the Node.js recipe is the closest starting point.
Not if your app reads posts at request time. With SSR the new post is live the moment your receiver stores it; with ISR or on-demand revalidation you revalidate that path. Only a fully static build needs a rebuild, and your receiver can trigger a Netlify build hook itself.
No card required. Signed test delivery in under a minute.