> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hiveku.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Webflow as the Content Source
> Point a project's New Content, Content department, SEO department and CMS panel at Webflow collections instead of Hiveku's own — what a writer's round trip then looks like, what the Webflow CMS trades away, and how to switch back.
Every Hiveku project has a **content source**: the CMS that New Content, the Content department, the AI and the CMS panel all write into. By default that is the Hiveku CMS, this project's own collections. Set it to **Webflow CMS** and all four point at the Webflow site's collections instead.
The switch is one setting, and Hiveku states its consequence in the same breath:
> Hiveku CMS keeps New Content, the Content department and the AI writing to this project's own collections. Webflow CMS points them at the Webflow collections instead: saving an entry stages it in Webflow, and Publish makes it live.
## Where the switch lives
**Webflow workspace → Settings → Content source.** Two options, Hiveku CMS or Webflow CMS. It takes effect within a minute.
Webflow CMS needs a bound site: "Choose a site under Connection first to use the Webflow CMS." If Webflow is turned off for the project under **Advanced**, the section says so and the choice is unavailable.
Under the hood the setting is one field on the project (`cms_provider`), written by `PATCH /api/builder/webflow/{projectId}/settings`. Every change that actually changes the value is recorded in the audit log, which matters for one recovery case described at the end of this page.
## What changes
The New Content modal lists this project's **Webflow** collections. The project row carries a **Webflow CMS** badge so you can see at a glance which CMS a draft is heading for.
The department card in the workspace changes from an instruction to a link: *"Publishes to Webflow CMS. Drafts written by the content department land in your collections."*
Page-SEO fixes become one Webflow page-metadata call rather than an edit to a source file. The result is reported as applied via Webflow, with `publish_required` set.
Hiveku's CMS panel asks `GET /api/builder/cms-files/{projectId}/capabilities` once and renders the Webflow surface: staged saves, a Webflow status line, Publish entry and Publish site.
The same seam carries the `cms_*` MCP tools and department chat: those tools write a Webflow collection when the project's content source is Webflow, with no separate tool set to learn.
Fields a Webflow page cannot hold — canonical URL, keywords, Twitter card, and Open Graph image, type and url — are reported back as **ignored** rather than silently dropped. An empty string is dropped too and reported, so an SEO run never blanks a field you did not mean to touch.
## The round trip a writer experiences
New Content, or a brief handed to the Content department. Pick the project (badged **Webflow CMS**) and one of its Webflow collections. The draft lives in Hiveku as a content item until you publish it to the CMS.
Publishing the content item writes a **staged** item in the Webflow collection and records the Webflow item id on the Hiveku row, so the two stay linked. If Webflow refuses — a rate limit, a validation failure — the real reason is stored on the content item and shown on its edit page, not swallowed.
The entry now opens in the CMS panel with a typed field editor. Saving stages the change in Webflow and the panel confirms **Saved to Webflow**, "Publish the site to make it live." The sidebar's Webflow section shows the item's real state in one line: *"Staged in Webflow. Publish to make it live."*, *"Draft in Webflow. Not on the site."*, or *"Live. Published 2 hours ago."*
**Publish entry** in the sidebar publishes that one item — it goes live without a site publish. **Publish site** beside it publishes the whole site, one per minute, and that pushes every staged change on the site rather than only yours.
Unpublishing a linked item from the marketing surface stages the item as a Webflow draft; the item stays on the live site until the next publish. Unpublishing from the CMS panel removes the live copy directly and leaves the staged one.
"Publish entry" and "Publish site" answer different questions. An item publish is the fast path for content. A site publish is what page titles, SEO, JSON-LD, custom code and redirects wait for — and it carries the one-per-minute cooldown, answering with the seconds remaining when you are inside it.
## What the Webflow CMS does not do
Hiveku's own CMS and Webflow's are not the same product, and the panel hides what Webflow cannot back rather than showing controls that would fail. Each row below is a real trade.
| Hiveku CMS feature | On Webflow | What to do instead |
| ------------------------------------------------------------------------------------------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Version history** per entry, with restore | Not available | Webflow keeps no per-entry version API. Treat a save as final, and keep the draft in Hiveku until you are happy with it. |
| **Shadow drafts** — autosave into a draft copy, edit safely beside the live entry, then promote | Not available | Webflow's model is different: a save **stages**, and Publish makes it live. Use the item's own draft flag to keep something out of the next publish. |
| **Wiring report** — "is any code file actually reading this collection?" | Not available | There is no Hiveku code to read the collection. Whether a Webflow collection is bound to a template is answered in the Designer. |
| **Preview write** — saves sync into a preview container | Not available | There is no Hiveku container. The staged Webflow site is the preview: the page editor's Staged view and `{short-name}.webflow.io`. |
| **Reader regeneration** — the typed content reader in your codebase | Not available | Nothing consumes one on a Webflow-backed project. |
| **Deploy-staleness banner** — "your live site is behind your content" | Not available | Webflow's model is publish, not deploy. The item's own status line and the Publish page's "changed since the last publish" count are the equivalent. |
| **Per-entry activity trail** in the CMS sidebar | Not available | The Webflow workspace's **Activity** page carries the account-wide trail: Hiveku writes plus the events Webflow sent back. |
| **Asset upload from a field** — Upload, Browse and the media library on an image, gallery or file input | Hidden; the URL input stays | Upload on the workspace **Assets** page, then paste the asset URL into the field. Uploads there are live immediately and need no publish. |
| **Atomic schema edits** — six endpoints for adding and changing collections and fields one at a time | Refused | Schema changes go through the additive manifest write, or the workspace **CMS → Fields** screen. Webflow cannot change a field's type, slug or options after creation at all. |
| **Back-references, cascade, scheduled publishing** | Available | These work the same on both. |
Two more shapes to expect:
* **Collection size.** A collection reads at most 2000 items in one pass, and item publishes go out in chunks of 100.
* **Degraded reads.** Collection lists are read from a snapshot where one exists, so a Webflow rate limit or a dropped connection gives you a stale list rather than an error. New Content marks it: **Webflow data may be stale**, with the hover reason. If the read failed outright the modal offers **Try again** and deliberately never offers "create a collection" — an empty list you could not read is not an empty CMS.
## Scheduled publishing on a Webflow entry
Scheduling stays available. Set a publish date on the entry and Hiveku's scheduler picks it up on the minute it falls due.
What it does on a Webflow-backed project differs from a Hiveku-hosted one in exactly one way, and the entry's own schedule card says it: **"Then publishes to Webflow automatically."**
Through the same provider write path a manual publish uses, so a scheduled entry and a hand-published one end up identical. Drafts stay drafts — scheduled publishing publishes the live entry's content, so promote a draft first if you meant to send it.
One Webflow **item** publish per project and collection, so ten entries falling due together cost one call rather than ten. An item publish is live on its own.
A site publish is a one-per-minute operation with cooldown semantics of its own, so the scheduler deliberately leaves it to you. If the scheduled entry's page also needs new SEO or new code live, publish the site yourself.
A failure before the flip releases the row for the next tick and records the reason; after five attempts it stops retrying and stays visible as a failed pending action you can reschedule or cancel. A Webflow rate limit hit while reading the collections is one of those retryable failures. Webflow can also accept a publish call and reject individual items in it; those rows are marked with the reason rather than reported as published.
Compare with [scheduled publishing on the Hiveku CMS](/cms/scheduled-publishing), where the scheduled time triggers a deploy of your site instead.
## Switching back
Set **Settings → Content source** back to **Hiveku CMS**. New Content, the Content department and the AI go back to writing this project's own collections within a minute. Nothing already written into Webflow is removed — those items stay in the Webflow collection, where they were always the source of truth.
Three other routes lead to the same place:
Under **Settings → Advanced**, "Turn Webflow off for this project": *"This project stops using Webflow and new content goes to the Hiveku CMS."* This hides the account's default connection from this one project without touching any other.
*"Disconnecting revokes the connection for every project that uses it and switches those projects back to the Hiveku CMS."* Owners and admins only, because it reaches every project on the connection.
A daily token-health check probes every active connection. Only **two consecutive** 401s mark it disconnected — a 403, a 429 or a Webflow outage is reported and never acted on. When a connection is marked dead, its projects drop back to the Hiveku CMS so writing does not simply fail, and an urgent "Reconnect Webflow" item appears in the inbox.
Reconnecting — by OAuth or by pasting a token — puts those projects back on the Webflow CMS. It will not override a choice you made yourself: if you explicitly picked the Hiveku CMS after the drop, that choice stands, which is what the audit record of every content-source change is for.
## What's next
The CMS, page and publish screens this page keeps pointing at, area by area.
The file-based CMS on the other side of the switch — versions, shadow drafts, wiring and deploys.