---
title: "Dock + Webflow: publishing workspaces with dual-keyed handshakes for sitewide changes"
excerpt: "Webflow stays the visual web canvas and CMS. Dock is where the agent's page-change queue, copy revisions, and reviewer approvals live, with a dual-keyed handshake before any sitewide publish or template change."
author: mei
category: Use Cases
date: "2026-05-30"
---

A Webflow publishing workspace runs on two surfaces. Webflow holds the visual canvas, the CMS collections, and the live site. Dock holds the change-request queue, the copy revision, the reviewer decision, and the two-key gate that fires before anything reaches production. The agent proposes; Dock records; a human reviewer signs; the publish API runs. Sitewide republishes and template edits never go out on a single agent signature.

Webflow stays the system of record for the canvas itself: pages, components, CMS collections, the published DOM. Dock is the system of record for what the agent and the team interpret around the canvas: the change brief, the review thread, the variation rationale, the approval status, the production-publish queue. Each Dock row carries a pointer to the platform record (`webflow_site_id`, `webflow_collection_id`, `webflow_item_id`), agent identity, decision, reviewer, and timestamp. The agent re-fetches Webflow state through fresh [Data API](https://developers.webflow.com/data/reference/rest-introduction) reads when it needs current values. Dock holds the persistent interpretive layer that survives across sessions and handoffs. This is the same split applied to Framer in the [Framer companion](/blog/dock-framer-web-design).

## The page-change queue

| change_id | webflow_site_id | scope | proposed_by | diff_summary | reviewer | status |
|-----------|-----------------|-------|-------------|--------------|----------|--------|
| ch_4119 | site_77a | cms_item: case-study-acme | agent.copy.mei | rewrite hero paragraph, swap CTA label | govind | approved |
| ch_4120 | site_77a | template: blog-post | agent.web.ved | add author byline slot to template | alex | pending |
| ch_4121 | site_77a | sitewide_publish | agent.web.ved | publish 14 staged items to live domain | govind | gate_open |

Row `ch_4121` is the dangerous one. A sitewide publish touches every staged item at once. Dock will not let a single agent close that row. It requires a second signature, which is the dual-keyed handshake described in [two-key handshakes for irreversible operations](/blog/two-key-handshakes-irreversible).

## A worked publish

The agent receives a brief: refresh the Acme case study, then publish. It reads the current item from the Webflow CMS API, drafts new copy, and writes `ch_4119` to the Dock queue with the diff and a pointer to the staged Webflow item. Govind opens the row, reviews the diff against the live page, and approves. The agent calls the Webflow publish endpoint scoped to that single item. Dock records the publish timestamp and the live URL on the row.

Then the agent proposes `ch_4121`, a sitewide republish to roll fourteen staged items live in one call. This hits the [dangerous-ops contract](/blog/dangerous-ops-contract). Dock opens the gate and freezes the row. The agent cannot publish. Govind reviews the batch, signs as the second key, and the publish API runs. Dock writes both signatures, the API response, and the deploy ID to the audit trail. That trail is what makes Webflow changes legible later, exactly as covered in [agent audit and compliance](/blog/agent-audit-and-compliance).

## Why this matters

Attribution is the first reason. Webflow's own activity log shows which API token published a change. Dock shows who briefed it, who reviewed it, why the copy reads the way it does, and which staged items were rolled in the same batch. When a stakeholder asks "why did the homepage hero change last Tuesday," the answer lives in the Dock row, not in a token log.

Handoff is the second. When the marketing lead rotates to a new agent, or the design team picks up a half-finished case study, the queue is the briefing. The new operator reads pending and recently approved rows and has the full context of what is in flight. No tribal knowledge, no Slack archaeology.

Daily-driver experience is the third. Designers keep working in Webflow. The canvas is unchanged. Dock sits beside it as the workspace where briefs land, where the agent posts proposed copy as a renderable diff per [agents render HTML](/blog/agents-render-html), and where the publish button is gated by a reviewer's signature. The Webflow [CMS API](https://developers.webflow.com/data/docs/working-with-the-cms) does the work; Dock decides when it runs.

Read the [Dock-for-Design overview](/blog/dock-for-design) for the full pattern across Figma, Framer, and Webflow.

## FAQ

**Does Dock replace Webflow?**
No. Webflow remains the visual canvas, the CMS, and the publishing engine. Dock holds the change-request queue, the reviewer decision, and the audit trail. Each Dock row points at a Webflow site, collection, or item by ID.

**What does the dual-keyed handshake actually block?**
Sitewide publishes, template edits that affect every page using that template, and CMS schema changes. Single-item updates can ship on one reviewer signature. The gate scope is configured per site.

**How does the agent know the current state of a Webflow page?**
It calls the Webflow Data API on demand. Dock never caches Webflow content as the source of truth. It caches only its own interpretive layer: the brief, the diff proposal, the reviewer decision.

**Can multiple agents work on the same Webflow site through Dock?**
Yes. Each row carries the proposing agent's identity, and the queue is shared. A copy agent and a design agent can have separate rows in flight on the same site, and the reviewer sees both.