Webflow sites start from scratch, from a template, or from a component library like Relume. However they start, they are built the same way: by hand, in the Designer, element by element.

There is now another way. An AI agent runs the build through Webflow's API while a developer directs the work, makes the design decisions, and verifies every change. The Designer stays closed for most of the construction. Design direction, content, and review stay human.

This article documents that method as JKJR Digital Development uses it in 2026: the two API surfaces, the build order, what the API can and cannot do, and the discipline the whole thing rests on. Check the published page, not the API response. Most of the testing ran on the pre-2.0 MCP server. Where MCP 2.0 changes the picture, the text says so.

A closed laptop on a dark surface with a glowing wireframe webpage assembling itself above it from floating blocks of structured code

The two API surfaces

Webflow exposes two programmatic surfaces. Both are reachable through the Webflow MCP server, and both write to the same unpublished site draft.

The Data API is headless. It needs no Designer session and covers site structure, pages, styles, CMS collections and items, components, assets, page SEO, custom code, and publishing. Nearly all construction runs through it.

The Designer API is live. It is reached through Webflow's MCP Bridge App inside an open Designer session and is used only for the operations the Data API refuses.

The point of the headless surface is that every change becomes text. A canvas change is a gesture: unreviewable before it happens, unbatchable, unreplayable. An API change is a structured call that can be planned, inspected, batched, and reproduced. That is what lets an agent do the construction while the developer supervises and controls publication.

Webflow supports this deliberately. Its documentation has an index for AI tools at developers.webflow.com/llms.txt, and any documentation page is available as markdown by appending .md to its URL.

The build sequence

The order matters. Each step depends on artifacts from the one before it.

Design tokens as site variables. Colors, type scale, spacing, and radii come first. Every style written afterward binds to a token, so a late design change is one edit. In testing, a contrast failure across several classes was fixed by changing one token. Deferring this step means a retrofit audit across hundreds of style declarations.
CMS schema. Collections, fields, and relationships are modeled and seeded before any page is built. When a repeating element varies per item, use a child collection with a reference to the parent, not a wide schema of per-slot fields. Both can be created and seeded through the API.
Styles. Query existing classes before creating new ones. New classes use three layers per section: background, width and padding, flex or grid arrangement. One concern per layer. The shape resembles Finsweet's Client-First convention; the motive here is a predictable structure for a programmatic operator. The style-assignment call only attaches classes that already exist. An unknown class name returns a partial success with a warning, and the element stays unstyled.
Element trees and bindings. The element builder constructs a whole section from one schema, including complete CMS Collection Lists. Element settings then bind text, rich text, images, links, and conditional visibility to CMS fields on template pages.
Componentization, selectively. Finished static sections become components so repeated instances stay consistent. Conversion strips element-level CMS bindings, so CMS-bound sections on template pages stay as plain element trees.
Publish and verify. Every task ends with a publish to the staging domain and an inspection of the published output. The publish endpoint allows one successful publish per minute, which enforces batching a task's changes into one publish. Production publishes, bulk deletions, and destructive CMS changes require explicit human authorization on any surface.

MCP 2.0 changes two things here. The conventions above can now live on the site as Agent Instructions (below), and the server's fuller awareness of site state reduces the read-before-write overhead. It does not change step 6.

Verified capabilities

Confirmed in published output during testing, not taken from documentation:

Arbitrary element trees, including Collection Lists with API-set source, sort, limit, and filter.
Element-level CMS binding on template pages: plain text, rich text, images, links, switch-driven conditional visibility.
Styles with variables as values, per-breakpoint styling, combo classes.
Full CMS management: schema, item creation and update, reference-field traversal.
Asset upload, static page SEO, component properties, slot filling, publishing.

In testing, a collection template page was rebuilt headlessly, new fields, a child collection, token-bound classes, and CMS-bound sections included, with only a few manual Designer actions.

Verified limitations

Each boundary below was found through a failed attempt during testing. Most are not in Webflow's published limitations for the MCP server.

Current-item links and filters. No API encoding for the "Current Item" page link or the "is Current Item" list filter. Workaround for links: a Link-type CMS field holding each item's path. The filter stays a one-click manual step.
Form controls. Select option values and input placeholders cannot be set through the API. Setting reserved form attributes creates orphaned duplicate fields; set field names in the settings interface.
Component slots. Raw elements cannot be appended into slots; component instances can. Unlinking an instance turns the slot into an ordinary container, at the cost of its CMS bindings.
Embedded code. HTML embeds cannot bind to component properties or CMS fields, so per-instance inline SVG via props is not possible.
Composite CSS values. A raw var() inside a gradient stop or shorthand is not stored as written. The parser collapses the property to the first variable it matches (independently reported). Raw references are safe only as a property's entire value.
Custom code. The Data API's custom code surface registers scripts at site level and applies them per site or page. The legacy free-text head and footer boxes in page settings have no API surface and are invisible to audits. Route all code through registered scripts and keep the boxes empty.
Component-internal rebinding. CMS fields cannot bind to elements inside a component definition, only to page-level elements in a CMS context.

From Webflow's documentation, unverified here: the MCP server cannot create Interactions, cannot create new localized CMS items in secondary locales, is scoped to one workspace per authorization, and cannot set variable modes on combo classes.

Throughput is the quantitative boundary. The general rate limit is 60 requests per minute by default, with HTTP 429 and a Retry-After header above it. For hundreds of style declarations and dozens of CMS items, that is a pacing constraint to plan around.

Verification is the method

Two wireframe pages side by side: a dashed, dim outline of the claimed change beside the solid, lit published page, one mismatched element highlighted

The most important finding is about evidence, not technique: a success response from the API is not proof the change exists. Testing produced four kinds of silent failure.

Writes that returned success and never persisted.
Builder-created text and links silently ignored at creation. One link read back correctly and published as href="#".
A conflict state when the same styles were edited in an open Designer session. Writes echoed success, read-backs showed the new values, and the published stylesheet never changed. The server reports Designer mode and returns ModeForbidden for disallowed tools, which makes this case notable: it produced no error at all.
Uploaded fonts registering under filename-derived family names, so style rules using the proper name fell back to system fonts. The failure is masked on any machine with the font installed, usually the developer's. Dozens of rules sat in that state until an audit of the published CSS exposed them.

The response is the same every time. The published output is the only trusted witness. Every task ends by publishing to staging, fetching the published HTML and CSS, and asserting the change is present. Webflow's activity log records agent changes and is useful as a record of intent, but every failure above also produced activity entries. Before any site-wide change, a script runs over the published CSS to produce the exact defect list, the fix goes in as one batch, and the result is verified the same way.

Context that lives on the site

A translucent glass building at night with glowing multicolored documents embedded in its stone foundation, feeding lines up into the structure

Agent Instructions are markdown rules and skills stored on the site and served to any agent that connects through the MCP server. They can reference the site's own variables, styles, components, and collections. That makes them the home for site-specific rules: the class-naming convention, the sections left uncomponentized, a component registry an agent must compose from.

The repository holds the rest: a short router saying which document answers which question, an append-only journal where nothing is recorded until it is verified in published output, and a register of every API limitation met, recorded once with its workaround. The split is clean. What is true of this site belongs in Agent Instructions. What is true of Webflow's API belongs in the repository, because it has to travel to other sites and workspaces. The site stops being only the output of the build and carries its own operating manual for whoever works on it next.

When not to build this way

Webflow also supports the other direction. DevLink exports components as React code, and Webflow Cloud deploys Next.js and Astro apps beside a site. A team whose source of truth is a codebase should start there.

The ceiling is workload shape. Rate limits, CMS item caps, single-level reference traversal, and no server-side aggregation make the Data API a poor backbone for dashboards, real-time features, or large data syncs. The method fits marketing sites with structured content, where the client owns the Designer and a content team needs the visual editor after handoff.

Precision at scale

A grid of hundreds of identical components in mint linework; a corner of drifted components glows amber as a beam of light straightens them

This article is credited as hybrid work, and its central claim was reached the same way. Half belongs to the developer, half to the agent.

The developer's half comes from one moment mid-build. Component construction was still partly manual, and manual first passes lose small details: spacing and sizing values off the scale, type off the ramp. The drift was noticed. The expectation, from years of tool-assisted work, was a partial fix, with the developer finishing the rest by hand. Instead the whole class of defect was corrected in one pass and verified against the published stylesheet. The surprise was the completeness. That is what the approach is for: precision at scale. Hundreds of small values correct at once is not something manual work reliably achieves. The failure it replaces is fatigue, not skill.

Reliability has its own history. Early live-canvas work through the Bridge App failed loudly: dropped tool calls, broken sessions, retries that interrupted the developer. When the MCP server moved from 1.0 to 2.0, the work shifted to the passive headless surface, where a failed call fails quietly and the agent absorbs it: adjusts, retries, routes around. Quiet failure is acceptable for one reason. Verification does not live in the call layer. It lives at the published output, where nothing quiet survives.

A stream of glowing packets crossing a dark field; one packet flickers out in red while the flow quietly routes around the gap

The agent's half answers the developer's question: did that correction change how components get built? It moved upstream, though not to perfection. An agent stays on a design system mechanically. Tokens exist before any style rule, classes are queried before they are created, and values bind to variables rather than raw numbers. It is not airtight. Under generation pressure a component ships with a hardcoded size where a token exists, the same miss a tired human makes. The difference is what happens next. The audit that once rescued the build runs as a standing pass over the published CSS, and what it finds is fixed as one batched correction. Drift was not eliminated. It was demoted from a design problem a client notices to a maintenance pass the log absorbs. The human defines what correct means. The machine holds correct at scale. The published page arbitrates.

What I like about it

I like working this way. The reasons are modest.

Construction becomes text. Changes can be planned, reviewed, batched, and replayed, and the record of what was done is the record of what was verified.
Systemic corrections are one pass. A class of defect found in the published CSS is fixed everywhere at once and checked the same way.
The result is an ordinary Webflow site, editable in the Designer and Editor, with no dependency on the tooling that built it.
Limitations, once found, stay found.

It is a method, not a promise. It does not make a project faster or cheaper on its own, and it does not touch the parts that take the time: design judgment, content, and review.

Field notes from the MCP 2.0 agency panel

In August 2026 Webflow hosted a panel on agency MCP 2.0 workflows with practitioners from VZA Digital, South, and Craft and Crew. Their rules match the ones above: nothing publishes through MCP without human review; work on a duplicate of an existing site and audit its design system first; have the agent scan and summarize the site before asking for work; constrain it to composing existing, well-named components; require a stated plan and proceed in small steps. A build stalled on rate limits during the panel's own demo. Same rules, reached independently.

Conclusion

Programmatic Webflow development works, within known limits. The API's gaps are bounded, enumerable, and stable enough to document once and route around. The method demands one discipline, verification against published output rather than API responses, and rewards one habit, recording every limitation the first time it appears. The first build pays for finding the boundaries. Later builds inherit them.

JKJR Digital Development builds and migrates Webflow sites for businesses in Northern Virginia and the DC metro area, in conventional builds and, where it fits, with the hybrid workflow documented here.

Like the work it documents, this article is hybrid work: drafted with AI assistance, then directed, edited, and verified by a human.

Programmatic Webflow Development: A Hybrid AI + Developer Workflow