> ## 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.
# The Webflow AI Chat
> Ask the AI in plain words to change CMS items, page titles, SEO, assets, scripts and publishing on a Webflow site, and know before you ask what it will refuse and the exact words it uses.
The [Webflow workspace](/integrations/webflow/workspace) ships with an AI chat that drives your Webflow site through the Webflow Data API. You describe the change; the chat calls the same operations the panels call, behind the same gates. It never writes project files, because a site that stays on Webflow has no Hiveku code to write.
This page covers where the chat lives, what it will and will not do, and how to phrase a request so it lands the first time. If you have not connected a site yet, start with [Connecting Webflow](/integrations/webflow/connecting).
## Where the chat lives
A resizable pane on the **left** of `//dashboard//webflow`, mounted before the rail so the AI works the site while the panels stay on the right. It remembers its width and open state per browser and opens by default on screens 1280 px and wider.
SEO, Content, PPC and the rest reach the same Webflow operations from their own chats. Pin the department to the site by passing the project id; without it the department works at account level and cannot touch the site.
The iOS app carries a site chat for external Webflow projects, with the same locked mode, the same starter prompts and the same capability wording as the web workspace.
The mobile app deliberately copies the workspace's capability and gate wording verbatim rather than writing its own, so the phone and the browser never disagree about what Hiveku can change. It adds one line the web does not need: **Open this site in Hiveku on the web**, because the phone cannot run the connect flow.
## Webflow mode, and why it is fixed
Every turn in the Webflow workspace runs in a dedicated **Webflow** chat mode. The mode dropdown stays visible in the composer, but it is locked, and hovering it gives the reason:
> This site lives on Webflow, so every change goes through the Webflow API. Other modes need a Hiveku-hosted project.
The lock is not cosmetic. A server-side guard decides the mode before the turn runs, and it wins over whatever the client asked for:
| Situation | What happens |
| ----------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| A Webflow-bound project with an effective connection and a bound site | Always runs in `webflow` mode, whatever mode was requested |
| A Webflow-bound project with no connection, or a connection with no site picked yet | The turn is refused with `422 webflow_site_not_connected` |
| A project that has code (anything not external) asking for `webflow` mode | Refused with `422 webflow_mode_requires_webflow_site` |
| Any other external site (WordPress, a plain tracked URL) | Refused with `422 external_site_has_no_code` |
The guard exists because of a real failure: a turn on a Webflow site used to run the ordinary Next.js coder prompt against an empty workspace and persist whatever the model wrote as phantom project files. The Webflow mode carries `edit: false` in its definition, so the mode cannot write project files at all.
The chat's own role definition says the same thing in one sentence:
> You operate a site that stays on Webflow through the Webflow Data API. You change CMS content, page titles, slugs, SEO and Open Graph, assets, custom code, form submissions, comments, ecommerce orders and publishing. You never write project files: pages, layout and styling live in the Webflow Designer.
## What to ask for
The composer offers five starter prompts, and they are a fair map of the surface:
* Draft 5 blog posts into the Blog collection
* Rewrite every page's SEO title and description
* Add our GA4 tag to the site
* What changed since the last publish?
* Publish the site
Anything in the table below works the same way. These are written to be pasted and edited.
| What you want | Something you can paste |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| CMS content | `Draft three case studies into the Case Studies collection using the client names in the brief, one per client, and leave them staged.` |
| A CMS field or collection | `Add a "Read time" number field to the Blog collection and fill it from the word count on the last ten posts.` |
| Page titles and SEO | `Rewrite the SEO title and meta description on every page under /services so each one names the service and the city, under 60 and 155 characters.` |
| Open Graph | `Set the Open Graph title and description on the pricing page to match its SEO title and description.` |
| Structured data | `Add FAQPage JSON-LD to /faq built from the questions already on the page.` |
| Assets | `Upload these four images to the asset library and set alt text describing what is in each one.` |
| Scripts and tags | `Register our GA4 tag and apply it site-wide, then tell me what still needs a publish.` |
| Forms | `Show me the submissions on the Contact form from the last week and mark the three obvious spam ones as spam.` |
| Comments | `List the unresolved Designer comments and reply to the one about the hero copy saying we shipped it.` |
| Ecommerce | `Set the stock on SKU 8412 to 40 and fulfil order 1093 with tracking number 1Z999.` |
| Publishing | `Publish the site to the custom domains and tell me which pages changed since the last publish.` |
| Orientation | `What can you change on this site, and what would I have to do in the Designer?` |
Say what you want changed and where, not which API to call. The chat resolves collections, fields, pages and forms itself, and its own rules tell it to read before it writes: collection field slugs before an item write, the page list before a metadata write, the current site custom code before applying a script.
## What it refuses, and the words it uses
Webflow's Data API cannot create, delete, rename or reorder pages, add, move or style elements, edit classes, components, interactions or variables, change page text in the primary language, author forms, or add locales. Rather than trying and failing, the chat refuses with one fixed script and does nothing else:
> Through Webflow's API Hiveku can change CMS collections, fields and items; page titles, slugs, SEO and Open Graph; images and files in Assets; custom code and scripts; form submissions; comments; ecommerce; publishing. It cannot create or delete pages, add, move or style elements, edit classes, components, interactions or variables, or change page text in the primary language. For that, open the Webflow Designer or convert this site to a Hiveku-hosted project.
It then offers the closest thing it actually can do: a CMS item, a redirect, an SEO change, a script.
The primary-locale limit is Webflow's, not Hiveku's. Webflow's own documentation states that API-based updates to page and component content are limited to secondary locales, and that primary locale content for pages and components must be updated through the Webflow Designer. CMS item content is the exception: that is writable in both the primary and secondary locales.
If the site has a secondary locale, page and component text becomes writable **in that locale only**. With one locale, the workspace says so once:
> This site has one locale. Webflow's API only writes page and component text in a secondary locale. Add one under Localization in Webflow, or edit this text in the Designer.
Page titles, slugs, SEO, Open Graph and JSON-LD are not affected by this. Those write the primary locale and need no secondary locale at all — the gap is page **body** text.
### Three other refusals worth recognising
| The chat says | Why | What to do instead |
| ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Custom code and webhook endpoints refuse site API tokens | The connection is a pasted site token; 15 operations are OAuth-only and return `412 oauth_required` | Reconnect the site with Webflow OAuth, or copy the tag out of Hiveku and paste it into the site in Webflow |
| Redirects, robots.txt, llms.txt, well-known files and activity logs need a Webflow Enterprise workspace | Webflow answers those endpoints `not_enterprise_plan_site`, which Hiveku maps to `402` | Manage 301 redirects and robots.txt by hand in the site's Webflow settings |
| Ecommerce is not enabled on this Webflow site | The store is off on the site itself, which is a site setting, not a plan tier | Turn on Ecommerce in the Webflow Designer |
## Confirmations
The chat asks before anything it cannot undo through the API and before anything every visitor sees at once. Nineteen operations are confirm-gated, and a gated call without the confirmation is refused with `412 confirm_required` rather than run.
The gated set is deliberately small — the reasoning in the code is that a gate everyone always satisfies has stopped being a gate:
* **Deletes:** a CMS item, a bulk item delete, a collection and every item in it, a field and its data, an asset, a form submission, a Google tag, every script Hiveku applied to the site, every script Hiveku applied to one page, a redirect, a robots rule, the site's llms.txt, well-known files, a webhook
* **Money and fulfilment:** fulfilling an order, refunding an order
* **Everyone sees it:** publishing the site
* **Changes another system's wiring:** replacing robots.txt, updating a webhook
The chat's own rules are explicit here: ask in plain words, wait for a yes, and never assume consent. A confirm-gated action that is asked for twice in the same breath still gets one question.
Publishing has a second gate on top of the confirmation. Webflow allows one successful publish per minute per site; a second inside that window answers `429 publish_cooldown` with `retry_after_seconds`, and the chat reports the wait rather than hammering the endpoint.
A site publish ships **every** staged change on the site, not only the ones the chat just made — including work a teammate, another agent or a Designer session staged and has not mentioned. Before you say "publish the site", ask the chat what changed since the last publish, or check the count on the workspace's Publish page.
## Changes land staged
This is the single most useful thing to know about the chat.
| What the AI changed | Where it is now | What makes it live |
| ----------------------------------------------- | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| A CMS item (created or updated) | Staged in Webflow, and **created as a draft by default** | Clearing the draft flag, then publishing the item — which goes live without a site publish. A publish skips any item still marked draft |
| A page title, slug, SEO or Open Graph | On the staged site | A site publish |
| JSON-LD schema markup | On the staged site | A site publish |
| A registered or applied script, or a Google tag | Registered on the site, runs only on the published site | A site publish |
| A redirect or robots.txt rule | Stored on the site | A site publish |
| An asset upload or alt text change | Live in the asset library immediately | Nothing — no publish needed |
Every reply ends with one line saying what is staged and what is live, so you never have to guess whether a change is visible to a visitor yet.
A new CMS item is created as a draft (`is_draft` defaults to true), and an item publish skips anything still marked draft. Ask the chat to clear the draft flag before you ask it to publish, or say so in the same request. Draft also keeps an item out of the next publish; it never unpublishes an item that is already live. To take a live item down, unpublish it.
## When the chat will not start
The composer only mounts once the workspace has a connected site with a site picked, because every turn before that is refused server-side anyway. Until then the pane shows one line and the action that fixes it:
| State | The line | The action |
| ------------------------- | ------------------------------------------------- | --------------- |
| Checking | Checking the Webflow connection | — |
| Not connected | Connect this site to Webflow to chat about it. | Connect Webflow |
| Connected, no site chosen | Pick a Webflow site in Settings to chat about it. | Choose a site |
| The check failed | Could not check the Webflow connection. | Retry |
Site details in the workspace — custom domains, locales, the live address, the last publish time — come from a cached row rather than a live read, so every surface says when Hiveku last looked and Settings carries a **Refresh from Webflow** action. The chat is told the same thing: never state a domain or a locale from the cached snapshot as current.
## Reaching the same operations from your own tools
The chat is one client of the Webflow operation registry, not a special case. The same 110 operations are exposed as MCP tools named `webflow_`, so an MCP client can drive the site the same way with the same gates and the same error codes. See [Hiveku for Claude Code](/integrations/claude-code-plugin) and [LLM Connectors](/integrations/llm-connectors) for how to connect one, and [Webflow for Developers](/integrations/webflow/developers) for the operation surface and its error map.
## What's next
The rail, the panels, the page editor and the publish etiquette the chat obeys.
The Webflow triggers and action nodes, and a worked recipe from a published item to a social draft and a Slack ping.
Point New Content, the Content department and the CMS panel at Webflow collections.
The OAuth model, what is stored, the inbound receiver, the crons, and the full error map.