> ## 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.
# Connecting Webflow
> Connect a Webflow site to Hiveku with OAuth (or a pasted site API token), choose which site each project uses, understand what Hiveku stores and how the token is protected, and re-register webhooks so form submissions and events start flowing.
Connecting is a one-time action per Webflow account. Most teams connect once at the account level and every project inherits it; agencies running several Webflow accounts in one workspace connect more than one and bind each project to the right site.
There are two connection kinds. **Webflow OAuth** is the full connection and the one to choose. A **pasted site API token** is the lesser alternative: it covers everything except fifteen OAuth-only actions, so CMS, page titles and SEO, assets, forms, comments, ecommerce and publishing all work, but it cannot install custom code and cannot register webhooks, which means no inbound events and no form routing.
Both kinds are stored the same way, resolved by the same rules and pass the same gates. The only difference is what Webflow will let the credential do.
## Before you start
You need an account on the Webflow workspace that owns the site, with enough rights to approve a Data Client app on Webflow's consent screen. Hiveku never asks for your Webflow password.
Connecting runs against the Hiveku account you are signed in to. **Disconnecting** and **re-registering webhooks** additionally require the owner or admin role, because both affect every project on the connection.
Hiveku picks the OAuth client for you, in this order: your account's own registered Webflow Data Client app, then Hiveku's own app where the environment provides one, then the first Webflow app registered on your account. When none of those is available, the hub offers the pasted site API token instead.
## Connect with Webflow OAuth
Go to `/dashboard/projects/settings/webflow`. It lists every connection on the account with its sites, the projects bound to each site, and the actions: Connect, Paste a site token, Reconnect, Disconnect, and **Create Hiveku project for this site**.
You can also start from a project: the Webflow workspace shows a connect card, and project **Settings** has the same buttons.
Hiveku opens a popup at `https://webflow.com/oauth/authorize`. The authorize URL is global — Hiveku collects nothing site-specific beforehand, because **you** pick which sites to share on Webflow's own screen.
On Webflow's consent screen, choose the workspace and select the sites this connection may reach. Share one site or several; a connection that reaches several sites is fine, and each project then picks the one it works on.
The popup closes and Hiveku, in one pass:
* exchanges the code for a bearer token,
* reads the granted permissions and your plan's rate limit, the authorizing user, and the sites you shared with their custom domains and locales,
* encrypts the token and mints a per-connection webhook URL secret, storing only its hash,
* saves the connection, its sites and the project binding in a single transaction.
After the save, and without ever being able to fail the connect itself, Hiveku registers its receiver webhooks on every shared site, puts back any project a failed connection had dropped to the Hiveku CMS, and indexes the bound project's pages for Review. If a site's registration only partly succeeded you get an inbox item naming it.
Webflow does not support PKCE and signs nothing on the redirect, so the signed state Hiveku creates at the start — carrying the account, the intent and the app, with a five-minute lifetime — is the whole cross-site-request defence. A cancelled consent still returns to Hiveku as a clean failure rather than hanging.
### What you are approving
Hiveku requests 22 permissions, the same set every time, so that the workspace does not have to ask again the first time you use a page:
| Area | Scopes |
| ------------------ | --------------------------------------- |
| Sites | `sites:read`, `sites:write` |
| Pages | `pages:read`, `pages:write` |
| CMS | `cms:read`, `cms:write` |
| Assets | `assets:read`, `assets:write` |
| Forms | `forms:read`, `forms:write` |
| Custom code | `custom_code:read`, `custom_code:write` |
| Components | `components:read`, `components:write` |
| Ecommerce | `ecommerce:read`, `ecommerce:write` |
| Comments | `comments:read`, `comments:write` |
| Site configuration | `site_config:read`, `site_config:write` |
| Site activity | `site_activity:read` |
| Authorizing user | `authorized_user:read` |
Two things are deliberately **not** requested. No `users:*` scope, because the Users and Access Groups endpoints no longer exist in the Data API and asking for a permission the consent screen cannot grant fails the whole authorization. No `workspace_activity:read`, because that endpoint takes a workspace token this integration never holds.
An action whose permission is missing answers with a clear "reconnect to grant it" error rather than a broken screen. `site_activity:read` was added after the first connections were made, so a long-lived connection may need one reconnect before the Enterprise activity log works.
## Choosing the site a project uses
A connection can reach several Webflow sites, so **the project picks one**. Open the Webflow workspace's **Settings** page and use the **Connection** section; until a site is chosen the workspace says so, the chat composer stays closed, and every action would have nothing to target.
The **Advanced** section holds the mode:
| Mode | What it means | Effective connection |
| ----------------------------------------------------------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------- |
| **Use the account's default connection** (`inherit`, the default) | The connection set as the default for this account. Most projects use this. | The account default, or none if there is no default. |
| **Use a specific connection for this project** (`override`) | Pick a connection and a site under Connection; they apply to this project only. | The chosen connection and its bound site. |
| **Turn Webflow off for this project** (`disabled`) | This project stops using Webflow and new content goes to the Hiveku CMS. | None, even if an account default exists. |
Resolution is simply: an override wins, then the account default, then nothing. A disconnected connection is never resolved.
Prefer `inherit` unless a project genuinely needs a different Webflow account or a different site. Fewer bindings means fewer things to fix after a reconnect.
The same Settings page holds **Content source**, which decides whether New Content, the Content department and the AI write to this project's own Hiveku collections or to the Webflow collections. Choosing Webflow CMS needs a site chosen first. See [CMS and content](/integrations/webflow/content).
## The pasted site API token
Reach for this when you cannot run OAuth on the workspace, or when you deliberately want a credential scoped to one site.
In Webflow open **Site settings**, then **Apps and integrations**, then **API access**, and generate a token with read and write access to sites, pages, CMS, assets, forms and comments.
Use **Paste a site token** on the account hub, or **Paste a site API token** on the project's connect card or in project Settings. From a project you can also tick the option to make Webflow that project's CMS at the same time.
The token is checked against Webflow first — the granted permissions and plan rate limit, and the sites it can actually reach — and only then encrypted and saved. It is never echoed back to the browser.
**What a site token cannot do.** Fifteen of the 110 actions require an OAuth connection and refuse a site token with a plain message rather than a confusing upstream error:
* the nine custom-code actions (registering scripts, site head and footer code, applied-script listing, and installing or removing a Hiveku snippet),
* the three page-level custom-code actions,
* creating and updating a webhook,
* reading the authorizing user.
In practice that means: **no inbound events and no form routing**, because both need a webhook registration; **no one-click analytics or annotation install**, because both are registered scripts; and **no site head or footer code** through Hiveku. Google tags do work with a site token, and deleting a webhook is not blocked.
Hiveku still attempts the webhook registration when you paste a token, because the refusal is Webflow's to give. When Webflow declines, the answer says the registration was skipped and returns the receiver URL **once**, and an inbox item carries the same URL with the manual instructions for registering the webhook yourself in Webflow.
One more difference worth knowing: a site-token connection cannot verify Webflow's HMAC signature on an inbound delivery, so the per-connection URL secret is the whole check on that connection.
## What Hiveku stores
Everything lives on one connection row per Webflow account or token.
| Field | Storage |
| ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| The Webflow bearer token (OAuth access token or pasted site token) | **Encrypted at rest**, AES-256-GCM envelope. Never plaintext, never returned by an API, never logged. |
| Granted permissions | Plain, so drift from the requested set can be detected and named. |
| Authorizing user email, workspace id | Plain. Null for a site token, which has no authorizing user. |
| Plan rate limit per minute | Plain, learned from Webflow on the first check. |
| Webhook URL secret | Only its SHA-256 hash. The secret itself exists only inside the registered endpoint URL. |
| Connection timestamps: installed, last checked, last synced, disconnected | Plain. |
| Each shared site: name, custom domains, locales, last publish | Plain, as a cached snapshot the workspace labels with when it was read. |
The encryption key is Webflow-scoped (`WEBFLOW_TOKEN_ENCRYPTION_KEY`), so a leak of it cannot open any other integration's credentials. Rotation is supported through `WEBFLOW_TOKEN_ENCRYPTION_KEY_PREVIOUS`: decryption falls back to the old key and each token re-wraps with the new one on its next write. If the key is missing, the connect routes fail up front rather than opening a popup and dropping the token afterwards.
OAuth tokens from Webflow **do not expire and carry no refresh token** — a connection stays valid until it is revoked or the app is uninstalled. That is why the health check below matters more than an expiry date.
## Do this once after connecting: re-register webhooks
Webhooks are what make form submissions, published items, page changes, comments and site publishes reach Hiveku. A fresh OAuth connect registers them for you. Run the re-registration when any of these is true:
* the connection was made before Hiveku registered webhooks and you want them without reconnecting,
* a health inbox item says deliveries have stopped reaching Hiveku,
* the Webhooks page in the workspace shows registrations you do not expect, or none at all.
The action lives on the Webhooks page and on the health inbox item, and calls `POST /api/builder/webflow/connections/[id]/reregister-webhooks`. It re-registers Hiveku's receiver on **every site of the connection** at the current endpoint URL, and per site it creates the new registrations first and deletes the old ones last — so a failure part-way leaves duplicates, never a gap. Duplicates are harmless: the receiver rejects a repeated event.
Re-registration is account-wide, so it is limited to owners and admins — the same gate as disconnecting. On a site-token connection it stops immediately, because Webflow will not accept the registration at all.
Hiveku registers 11 event types per site: site publish, the five collection item events, page created, page deleted, page metadata updated, form submission and comment created. What happens to each is covered in [the Forms area of the workspace](/integrations/webflow/workspace#forms) and in [the inbound webhook receiver](/integrations/webflow/developers#the-inbound-webhook-receiver); a routed submission lands in the Forms ledger, creates or updates a CRM contact, and can start a workflow with the Form Submitted trigger. See also [Managing form submissions](/how-tos/manage-form-submissions).
## Reconnecting
Reconnecting runs the same OAuth flow against an existing connection and refreshes the token, the granted permissions and the site list **on the same row**, so project bindings and the account default survive. Use it when:
* an action reports a missing permission,
* the connection was marked disconnected after repeated authorization failures,
* you want the site list refreshed after adding or removing sites in Webflow.
A site-token connection has no OAuth grant to refresh; you paste a new token instead, which reaches the same sites and restores the same projects.
A reconnect also puts back any project that an automatic health check had dropped to the Hiveku CMS. It never overrides a deliberate choice: a project you disconnected yourself, or one you explicitly moved to the Hiveku CMS after the fact, stays where you put it.
**How a connection is judged unhealthy.** A background check probes each active connection. Only **two consecutive authorization failures** mark a connection disconnected, move its projects back to the Hiveku CMS and raise an urgent "Reconnect Webflow" inbox item. Rate limits, permission errors and Webflow outages are reported and never acted on, so a bad afternoon at Webflow does not unbind your sites.
## Disconnecting
Disconnect from the account hub, or from the **Disconnect** section of a project's Webflow settings. It is account-wide and limited to owners and admins.
Disconnecting revokes the connection for **every project that uses it** and switches those projects back to the Hiveku CMS.
What happens, in order: Hiveku deletes its receiver webhooks on Webflow first (a revoked token could not delete them afterwards, and a registration is only dropped locally once Webflow confirms), then revokes the OAuth grant on Webflow's side where there is one, then marks the connection disconnected and flips every project whose CMS was served by one of its sites back to the Hiveku CMS. The projects that moved are reported by name so you can see the blast radius before you refresh.
The row itself stays for audit and for a later reconnect. And the choice is remembered: a project moved to the Hiveku CMS by **your** disconnect is treated as a deliberate choice and is not silently put back on Webflow by a future reconnect.
## What is next
What the integration changes, what stays in the Designer, and the primary-locale limit.
The 27 pages behind a connected site, and the AI chat locked to Webflow mode.
Point New Content and the Content department at your Webflow collections.
The Forms ledger, CRM contacts, and importing the submissions Webflow already holds.
What to ask for once the site is connected, and what the AI will refuse.
Start a workflow from a Webflow event, and drive the site back through the action nodes.