Last updated: August 29, 2026 · By Vishal Swami, Founder & Lead AI Reviewer, AISagely
Wagtail 8.0's new v3 API is a preview REST API that, unlike the old read-only v2 API, can create, edit, and publish content — which is what lets an AI agent or a script manage a Wagtail site instead of just reading it. Wagtail's team is calling this "CMS with AI, not AI CMS" on purpose: no built-in chatbot bolted onto the admin, just a general-purpose API you point automation at.
Short answer: Wagtail 8.0, released August 25, 2026, ships a preview v3 REST API built on Django Ninja that adds write access — create, update, publish — on top of the old read-only v2 API. Enable it with three lines of settings, generate a token from Settings → API tokens, and any script or AI agent with an HTTP client can manage pages, images, and documents through it.
In my testing, I spun up a throwaway Wagtail 8.0 project, added wagtail.api.v3 to INSTALLED_APPS, mounted the URLs, and had a page created and published through a curl request in under ten minutes — no admin login, no clicking through the page editor. That's the whole pitch: Wagtail isn't shipping a content-generation feature, it's shipping the plumbing so you can wire your own AI workflow — a script, an agent, a Claude-powered content pipeline — directly into publishing.
What you'll need
A Wagtail 8.0 project (the v3 API doesn't exist on 7.x or earlier), and Python/Django familiarity to edit settings.py and urls.py. You'll also need shell access to run a management command, since token creation happens via ./manage.py, not the admin alone — though there's an admin-UI path too if you'd rather skip the command line. No paid plan or SaaS account is required: Wagtail is open source under the BSD 3-clause license, free for commercial and non-commercial use, with no tiers or seat limits on the CMS itself. Budget for hosting and, if you're wiring in an actual AI agent, whatever that model costs to run.
Step-by-step: enabling the Wagtail v3 API for AI agents
1. Add the v3 API to your project
Add wagtail.api.v3 to INSTALLED_APPS in settings.py, then mount it in urls.py:
“`python from wagtail.api.v3.urls import api
urlpatterns = [ path("api/v3-preview/", api.urls), ] “`
Wagtail's own docs recommend the /api/v3-preview/ path specifically while this is a preview release, so you can retire it cleanly once the stable v3 path lands in 8.1.
2. Generate a token for the agent or script
From the admin, go to Settings → API tokens, or run it from the shell:
“bash ./manage.py api_tokens create --user=deploy --name="deploy bot" “
The secret is shown once, at creation — save it immediately, because there's no way to view it again afterward. In my testing I created a dedicated deploy user for this rather than reusing my own admin login, which the docs also recommend: a token inherits whatever permissions its user account has, so a service account with narrow permissions limits the blast radius if a key leaks.
3. Confirm the token works
Hit the whoami endpoint before doing anything else:
“bash curl -H "Authorization: Bearer wagtail_..." https://example.com/api/v3/whoami/ “
A working token returns the authenticated user's profile and group memberships. If you get anonymous access back instead of a user object, the token is missing, malformed, or wasn't sent as a Bearer token — this was the one step where I fat-fingered the header format on my first try and got silently treated as an anonymous read-only request rather than a clear error.
4. Create and publish a page in one call
“json POST /api/v3/pages/ { "meta": { "type": "blog.BlogPage", "parent_id": 3, "action": "publish" }, "title": "Example", "slug": "example" } “
Set meta.action to "publish" and the page goes live immediately; leave it out and Wagtail saves a draft instead. This is the part that didn't exist before 8.0 — the v2 API could hand you page data, but it had no path to write any of it back.
5. Edit or publish an existing page separately
Use PATCH /api/v3/pages/{page_id}/ for a partial update — omitted fields and child relations are left alone — or POST /api/v3/pages/{page_id}/actions/publish/ to publish whatever revision is already sitting in draft. Keeping edit and publish as separate calls matters for an agent workflow: you can have a script draft ten posts and require a human to fire the publish call on each one.
6. Wire an agent to the API, not the admin
Point your AI agent's tool-calling or MCP setup at these endpoints instead of trying to automate the browser-based admin UI. My MCP-Builder.ai rundown covers scaffolding an MCP server around exactly this kind of REST API if you want an agent like Claude to call it through a defined tool rather than raw HTTP.
Example prompts you can copy
These assume you're handing the integration work to a coding agent rather than writing every line by hand:
- "Write a Python script that authenticates to the Wagtail v3 API with a Bearer token from an environment variable, then creates and publishes a
blog.BlogPageunder parent ID 3 from a title and Markdown body I pass in." - "Build an MCP tool that wraps
POST /api/v3/pages/{id}/actions/publish/so an agent can publish a specific draft page by ID without seeing the rest of the API surface." - "Review this Wagtail v3 API integration and flag anywhere we're using an admin superuser token instead of a scoped service account."
- "Write a script that calls
GET /api/v3/whoami/first and exits with a clear error if the token is invalid, instead of silently falling back to anonymous access." - "Generate a batch script that PATCHes the search description field on every page under a given parent ID, for a bulk SEO cleanup pass."
Ways to give AI or scripts access to Wagtail content compared
| Approach | Write support | Setup effort | Best for |
|---|---|---|---|
| Wagtail v3 API (8.0 preview) | Full: create, edit, publish, move, copy | ~3 lines of settings/URL config + a token | Wiring agents or scripts directly into publishing |
| Wagtail v2 API | Read-only | Already on in most existing projects | Feeding page data to a static site or search index |
| Automating the Wagtail admin UI | Full, but through a browser | High — brittle, breaks on UI changes | Avoid; not built for automation |
| Third-party "AI CMS" platform | Full, but locked to that vendor's model/UI | Migration required | Teams wanting AI features built-in, not bolted on |
Common mistakes to avoid
The mistake I'd flag first: reusing your own admin account's token for an agent integration instead of creating a scoped service account — a token inherits its user's full permissions, so a leaked personal token can do anything you can do in the admin. Second, mounting the API at /api/v3/ instead of the recommended /api/v3-preview/ path; it works today, but you'll have a URL to migrate later for no benefit now. Third, skipping the whoami check and debugging a confusing "empty response" instead of realizing the request was silently treated as anonymous. Fourth, letting an agent call the publish action directly on every page it drafts — separating draft creation from the publish call is what gives you a human review step, and removing that step is a workflow decision, not a technical default. Fifth, assuming this is stable: it shipped as a preview specifically so the Wagtail team can change it before 8.1, so pin your dependency and read the changelog before upgrading.
Tools that make this easier
If you're serving this same content back out to AI crawlers and agents, not just letting them write to it, my guide to serving Markdown to AI agents with Accept headers covers the read side of this same problem — content negotiation so agents get a lean response instead of a full HTML page. For controlling which bots and agents reach your Wagtail site at all before you decide what they're allowed to touch, see Cloudflare’s AI traffic options. If you want an agent to call the v3 API as a proper tool instead of raw HTTP requests, MCP-Builder.ai is the fastest way to scaffold that. Claude and ChatGPT’s agent mode are both capable of driving this kind of integration once it's wired up as a tool. And for testing the whole pipeline somewhere disposable before it touches your production site, the pattern in my Docker sandboxes for AI agents guide is the same setup I used to run the throwaway project for this article. If you're writing the integration script itself, my best AI tool for code comparison covers which coding assistants handle this kind of API-wrapping cleanly on the first pass.
My take
The "CMS with AI, not AI CMS" framing is the right call, and it's a deliberate contrast with vendors bolting a chat panel onto their editor and calling it an AI feature. Wagtail 8.0 doesn't generate your copy or summarize your pages — it just stops being read-only, which is a smaller, more useful thing. In my testing, the setup was closer to "add a Django app" than "adopt a platform," and the token-scoping design (service accounts, one-time secrets, a dedicated whoami check) suggests the team thought about the failure mode of a leaked key before shipping this, which matters more than any feature list once you've actually pointed an autonomous agent at your production content.
Frequently Asked Questions
Is Wagtail's new v3 API free?
Yes. Wagtail itself is open source under the BSD 3-clause license with no paid tiers, so the v3 API costs nothing beyond whatever you already pay for hosting. There's no separate SaaS fee for enabling it.
How long does it take to set up the v3 API for an AI agent?
In my testing, going from a stock Wagtail 8.0 project to a published page via curl took under ten minutes: add the app, mount the URLs, generate a token, confirm it with whoami, then post the create request. Wiring a full agent integration with error handling and a review step takes longer — plan for an afternoon, not ten minutes.
What is the easiest way to get started?
Enable the API, create a dedicated service-account token from Settings → API tokens rather than reusing your own login, and test it with GET /api/v3/whoami/ before writing any create or publish logic. That order catches auth mistakes before they touch real content.
Is the v3 API stable enough to use in production yet?
It shipped in 8.0 as an explicit preview, with Wagtail's team collecting feedback ahead of refinements in 8.1 a few weeks later. Treat it like any preview API: fine for internal tooling and testing, but pin your version and expect some changes before it's marked stable.
Do I still need the v2 API if I switch to v3?
Only if something you already built depends on it. The v2 API keeps working — Wagtail isn't removing it — and v3 respects the same WAGTAILAPI_* settings, so the two can run side by side while you migrate at your own pace.