Webflow Developers Updates & Release Notes

Get page metadata now accepts translatable, alongside the endpoints that already supported it:

• Get page content
• Get component content and get component properties
• List and get collection items, including their live counterparts

Pass the id of the secondary locale you're translating into to omit page-level fields (title, slug, SEO title/description, Open Graph title/description) excluded from translation for that locale — they're left out of the response entirely rather than returned as null. Behavior matches the other endpoints: the value must be a secondary locale id (400 otherwise), and the request returns a 403 if translation exclusions aren't enabled for the site.

Original source

The translatable parameter introduced on July 27 couldn't express the workflow it was built for, so its shape has changed.

Why it changed

A translation integration reads the primary locale to get the source text, translates it, then writes the result to a secondary locale. As originally shipped, translatable=true resolved exclusion rules against the same localeId used to select the content, which left no way to do that first step correctly:

Requesting the primary locale returned the right content, but only matched exclusion rules scoped to "all languages" — rules scoped to a specific language were silently ignored, so you could receive content the site owner had excluded for the language you were translating into.

Requesting a secondary locale scoped the rules correctly, but returned content that was already translated rather than the source text.

What changed

translatable now takes the id of the secondary locale you're translating into, independent of localeId:

?localeId={primary locale id}&translatable={target locale id}

translatable=true and translatable=false now return a 400. Pass a locale id, or omit the parameter entirely.

The value must be the id of one of the site's secondary locales. The primary locale id, or any other value, returns a 400.

localeId is optional. Omitting it returns the primary locale's content, filtered for the target locale — the common case for a translation integration.

The parameter requires translation exclusions to be enabled for the site. If they aren't, the request returns a 403.

If the exclusion rules can't be resolved, the request returns a 500 instead of unfiltered content. Retry the request.

Required action: if you're passing translatable=true, replace it with the id of the locale you're translating into. If you're passing translatable=false, remove the parameter.

Affected endpoints

• Get page content
• Get component content and get component properties
• List and get collection items, including their live counterparts

Behavior that hasn't changed: only exclusion rules scoped to manual translation are respected, and omitting translatable returns the same response as if the parameter didn't exist.

Original source

Site owners can exclude specific fields, properties, or canvas content from AI translation using the Localization panel in the Designer.

These endpoints now expose those exclusion rules through a new translatable query parameter.

Translation pipeline integrations can fetch exactly the content that should be translated, without tracking exclusion rules themselves.

New parameter

Pass translatable=true along with a secondary locale to return only content that hasn't been excluded from translation for that locale:

• Get page content: returns only page fields not excluded for the requested locale.
• Get component content and get component properties: return only canvas content and properties not excluded for the requested locale.
• List and get collection items, including their live counterparts: return only collection fields not excluded for the requested locale.

Only exclusion rules scoped to manual translation are respected — rules scoped only to automatic translation don't affect the response. Omitting translatable returns the same response as before this parameter existed. Setting translatable=true without also specifying a secondary locale returns a 400 error, since exclusions are resolved per locale.

Original source

A minor (maintenance) release to improve how the Webflow MCP works with Claude. Three groups of actions moved out of two large tools into focused tools of their own. The actions themselves are unchanged (same inputs, same behavior).

Element settings

data_element_settings_tool takes over element settings and data bindings from data_element_tool: reading and writing settings, discovering bindable sources, and setting an element's tag, visibility, and DOM id (static or bound).

Component props

data_component_props_tool takes over prop work from data_component_tool: creating, updating, and removing prop definitions, reading an instance's props, setting prop values, and resetting all props to their defaults.

Component variants

data_component_variants_tool takes over variant work from data_component_tool: creating, duplicating, deleting, reordering, and renaming variants, and reading or setting per-variant styles.

Skills based on earlier versions of Webflow MCP may need to be updated. The skill migration guide covers the updated tools and actions.

Original source

Build without a Designer session

In earlier versions, working with elements, components, styles, and variables required an active Designer session through the Webflow MCP Bridge App. In 2.0, those capabilities work on their own:

• Query and edit the element tree: text, styles, links, images, attributes, tags, settings, visibility, and display names, plus moving and removing elements.
• Create, transform, and manage components, including instances, props, and variants.
• Create, update, rename, and remove styles (classes and combo classes), and manage per-style variable modes.
• Create, update, rename, and delete variables (color, font family, number, percentage, size), and build and reorder collections and modes.
• Build elements on a page from a schema, insert component instances (including nested trees), and insert elements from HTML and CSS.
• None of these need a Designer session anymore.

New capabilities

MCP 2.0 opens up five areas of Webflow that agents couldn't reach before. Each works without a Designer session.

Analyze reporting

Agents can work with Webflow Analyze data: pull traffic over a chosen window (sessions, users, or pageviews), rank a site's top pages, break down leading values for a dimension like country, browser, or traffic source, surface the most frequent engagement events with page context, and read time on page as an aggregate or over time. Available for sites with Webflow Analyze.

Forms and submissions

Agents can read a site's forms and their schemas, list and retrieve submissions (with optional element and locale filters), update the hidden fields on a submission, and delete submissions.

Custom fonts

Agents can list and inspect a site's uploaded custom fonts, register and upload new font files, replace the file behind an existing font, update font metadata, and remove fonts individually or in batches.

Sitemap indexing

Agents can read, list, update, and bulk-update sitemap inclusion for CMS collection items and static pages.

Agent instructions

Agent instructions are markdown-based skills and rules that give agents custom guidance for working on a site. They can reference Webflow primitives like variables, styles, components, pages, CMS collections and items, and locales, and those references resolve against the site's own data. In 2.0, these instructions are provided automatically to external agents, and agents can manage them directly: searching a site's rules and skills, reading them (with referenced instructions resolved inline), and creating, updating, moving, renaming, and deleting them.

Expanded existing tools

Several existing capabilities gained new actions in 2.0:

• Pages: create a page, update settings across many pages at once, and read and bulk-update page schema markup and structured data.
• Assets: full asset and folder management (list, get, update, delete, and organize into folders), plus asset compression jobs with task tracking.
• Custom code: read and write the freeform custom code embedded at the site and page level, alongside existing registered-script management.

Still requires a Designer session

A few capabilities still depend on an active Designer session (through the Webflow MCP Bridge App):

• Element snapshots. Capturing a visual snapshot of an element, so an agent can read the current state of a site and verify its own changes before publishing.
• Selection and canvas navigation. Selecting and reading the selected element, navigating the canvas between pages and component views, reading the current page, mode, and branch, reading a site's breakpoints, and creating page folders.
• Uploading an image from a URL. Adding an image to a site directly from a public URL.

Governance

MCP enforces your workspace's permissions and roles, including custom roles: if a user can or cannot do something in the Designer, the same applies through MCP. Changes made by agents are recorded to the site audit log. This means you can give external agents site access while keeping the same permissions and audit trail as the rest of Webflow.

Migrating from an earlier version

Several tools and actions were renamed or relocated in 2.0, so skills, prompts, and automations written against an earlier version may call names that no longer resolve. A few examples:

• set_id is now set_dom_id, and add_or_update_attribute is now set_attributes.
• Element selection and canvas navigation moved to the dedicated Designer-session capabilities described above.
• Full asset and folder management moved off the image-upload tool, which now handles uploading an image from a URL only.
• The skill migration guide lists every name that changed and what to replace it with. You can also point an agent at that page and have it update a skill on its own.

Known limitations

A few things to be aware of in this release:

• Element snapshots require a Designer session. Capturing a visual snapshot still depends on an active Designer session through the Webflow MCP Bridge App. If you want an agent to run independently, let it publish to a staging domain, which supports full agent loops without the Designer.
• One workspace per authorization. When you authorize the MCP server, you choose a single workspace it can access. To use a different workspace, reauthorize. In clients like Claude and ChatGPT, that means removing the connector and reinstalling it.
• Interactions (IX3) aren't supported. Agents can't create or apply Webflow Interactions through the MCP server. Build and edit interactions manually in the Designer.
• Custom fonts cover uploaded files only. The custom font capabilities manage font files you upload. Remotely hosted Google and Adobe Fonts are still managed manually in site settings. For Google Fonts, you can download the files and upload them through the MCP server.
• Some uploads require sending a file to a presigned upload URL. Uploading an asset, or uploading or replacing a custom font file, is a two-step flow: the tool returns a presigned upload URL, and the client sends the file's bytes directly to that URL. If the client's environment or network blocks that outbound request, the upload can't complete. In that case, upload the file manually in Webflow instead.

Original source

DevLink Export supports a new opt-in camelCaseVariantNames setting in webflow.json that converts Style Variant names into camelCase values for the exported variant prop.

What changed

New camelCaseVariantNames option under devlink-export in webflow.json. It's off by default, so existing exports are unaffected.

When turned on, a Style Variant named Papaya With Whip exports as papayaWithWhip instead of the raw display name. Names that would collide, or that would otherwise produce an invalid value (a number-only name, or a JavaScript reserved word), fall back to safe, deduplicated values.

To use

Set "camelCaseVariantNames": true under devlink-export in webflow.json, then re-run webflow devlink export.

For more information, see Configuration options.

Original source

The base variable mode

The base variable mode — the default set of values that variables fall back to — is now first-class in the Designer API. It has the reserved ID "base" and, by default, the name "Base mode".

You can now work with the base mode like any other mode:

Rename it with mode.setName(). Its ID stays "base" even after it's renamed.

Retrieve it by ID with collection.getVariableModeById("base"), or by its (default or renamed) name with collection.getVariableModeByName().

// Get the default variable collection
const collection = await webflow.getDefaultVariableCollection()
// Get the base mode by its reserved ID and rename it
const baseMode = await collection.getVariableModeById("base")
console.log(await baseMode?.getName()) // "Base mode"
await baseMode?.setName("Light")

Behavior change: getAllVariableModes includes the base mode

collection.getAllVariableModes() now includes the base mode in the returned array (as the first entry). If your integration iterates over the result, it will now encounter the base mode — for example, when listing or counting a collection's modes.

const collection = await webflow.getDefaultVariableCollection()
const modes = await collection.getAllVariableModes()
// The base mode is now part of this list
for (const mode of modes) {
console.log(await mode.getName())
}

For more information, see Variable Modes.

Original source

The Analyze API lets you read a site's analytics. Five reports are available now:

Analyze

• Traffic: a daily time series of sessions, users, or page views over a chosen window.
• Top pages: the most-visited pages, ranked by sessions, users, or page views, with an optional per-page time series.
• Top dimensions: the top values for a dimension you choose, such as country, device, traffic source, or audience.
• Top events: the most-fired events, ranked by how often they fire, with an optional daily time series per event.
• Time on page: the average time spent on a page, as a single value or bucketed by day or week.

Filter any report by dimensions like country, device, or traffic source.

Original source

The Analyze API (beta) lets you read a site's analytics. Five reports are available now:

Analyze

• Traffic — a daily time series of sessions, users, or pageviews over a chosen window.
• Top pages — the most-visited pages, ranked by sessions, users, or pageviews, with an optional per-page timeseries.
• Top dimensions — the top values for a dimension you choose, such as country, device, traffic source, or audience.
• Top events — the most-fired events, ranked by how often they fire, with an optional daily timeseries per event.
• Time on page — the average time spent on a page, as a single value or bucketed by day or week.

Filter any report by dimensions like country, device, or traffic source.

Original source

The Webflow CLI now uses app-named flags and an app-named manifest field for webflow cloud to match the "Apps" product naming. The legacy spellings keep working as deprecated aliases — you don't need to migrate immediately.

New flags on webflow cloud

New flag

Replaces

Available on

• -n, --app-name
--project-name
  cloud init, cloud deploy

• -a, --app-id
-p, --project-id
  cloud deploy

--project-name and --project-id continue to work as deprecated long-form aliases. Using either prints a warning pointing at the new spelling.

The -p short flag for --project-id was removed in favor of -a. Long-form --project-id still works.

Passing both spellings together (for example, --app-name X --project-name Y) errors instead of picking one.

For full options, see the cloud init and cloud deploy reference.

Renamed webflow.json manifest field

The cloud.project_id manifest field is now cloud.app_id. New deploys write cloud.app_id. Existing manifests carrying cloud.project_id keep working — the CLI reads the legacy field transparently as a fallback, so you don't need to update your webflow.json to keep deploying. A future major release will drop the legacy field.

{
  "cloud": {
    "app_id": "<Your App ID>",
    "framework": "astro"
  }
}

See the configuration reference for details.

Upgrading

npm install -g @webflow/webflow-cli@latest

Original source

It's now easier to deploy Astro and Next.js applications to Webflow Cloud.

You can click this button to walk you through the process of deploying a project from a GitHub repository to Webflow Cloud:

You can also pass the URL of the GitHub repository to Webflow Cloud, as in this example: https://webflow.com/dashboard/cloud/deploy?repo=https://github.com/Webflow-Examples/hello-world-nextjs.

You now have the option to deploy applications to Webflow Cloud without connecting them to a Webflow site.

Note that your Workspace now shows sites and these independent applications separately, as in this screenshot:

Applications that are part of a site are still shown in that site's settings, as in this screenshot:

For more information, see Bring your own app.

Original source

Breaking changes

CLI 2.0 consolidates the webflow library command group into webflow devlink and raises the Node.js minimum version to 22.13.0.

The commands from the previous version still work but emit deprecation warnings because they will be removed in a future version.

Node.js minimum version raised to 22.13.0.

Verify your Node.js version with node --version before upgrading.

Upgrading

Run this command to upgrade the Webflow CLI to version 2.0:

npm install -g @webflow/webflow-cli@latest

Then, verify the version of the CLI by running this command:

webflow --version

Renamed commands

These commands have been renamed.

The commands work the same way and take the same options.

Be sure to update scripts and CI to use the new commands.

Version 1 command

Version 2 command

Description

webflow library share

webflow devlink import

Bundles and shares components with a Webflow Workspace

webflow library bundle

webflow devlink bundle

Bundles a Code Component library locally without sharing it to Webflow

webflow library log

webflow log

Shows the path to the latest log file

webflow cloud create

webflow cloud init

Initializes a Webflow Cloud project from a template

For full options and examples, see the command reference.

Original source

What's exported

DevLink Component Export now ships interactions built with the new GSAP-powered Interactions engine.

Animations defined on a component, including triggers, timelines, and GSAP plugins, are exported and run in your React project with no extra setup.

For every component that has Interactions, DevLink now emits:

• Interaction registration code, wired through a new useIX3Interactions hook.
• A per-export GSAP bundle (webflow_modules/devlink-gsap.js) that contains only the GSAP plugins your site actually uses, such as ScrollTrigger, SplitText, and CustomEase.
• Plugin dependencies such as CustomBounce → CustomEase and ScrollSmoother → ScrollTrigger are resolved automatically.
• The IX3 runtime bundle (webflow_modules/devlink-ix3.js) that initializes GSAP and registers interaction data.
• GSAP plugin selection is driven by the site itself.
• No CLI flag or configuration is needed.

One provider, both engines

The <DevLinkProvider> component now wraps both Classic Interactions (IX2) and the new GSAP-powered Interactions (IX3).

There is no separate <IX3Provider> component to compose:

import { DevLinkProvider } from './devlink/DevLinkProvider';
import { AnimatedHero } from './devlink/AnimatedHero';

export default function App() {
return (
<DevLinkProvider>
<AnimatedHero />
</DevLinkProvider>
);
}

Existing Classic Interactions setups keep working unchanged.

Lazy by default

The IX3 runtime and GSAP bundle load on demand, only after a component that uses useIX3Interactions mounts.

Sites that don't use interactions, and pages that don't render an animated component, pay zero runtime cost: nothing is fetched and the bundles are never executed.

Framework support

Next.js (App Router and Pages Router, both Webpack and Turbopack): works in dev (StrictMode safe) and production builds.

Vite, Rollup, and esbuild: dynamic import specifiers are statically analyzable, so chunks are emitted cleanly.

Astro: works inside React islands.

As with any React context provider, place a single client:load directive on the wrapping component.

Two separate client:load islands won't share IX3 context.

Requirements

@webflow/webflow-cli v1.19.0 or later

Node.js v22 or later

To use

Update your Interactions so that they are scoped to the component that you'll export.

Then re-run the webflow devlink export command to pick up IX3 animations from your site.

No changes are needed in the webflow.json file.

For more information, see What's exported.

Original source

Components

Agents can now work with components end-to-end.

They can create blank components, define and manage props, set and reset prop values on instances, bind props to element settings and text, manage variants (including variant-scoped style variable modes), duplicate components, reorder variants, and unlink component instances.

They can now read and edit Text and Rich Text prop content.

In many cases they can set CMS field bindings as component props.

Component query results are now richer: responses can include props, instance counts, and variants.

Library components and code components (with their read-only and runtime flags) are now included in component lookup results.

Branching

Agents can now create, inspect, and delete page branches.

They can retrieve branch details and IDs for the currently active page.

Styles

Agents can now query styles by ID, name path (including combo classes), and CSS properties, with options to include breakpoint and property data.

They can create and update styles from raw CSS.

Elements

Agents can now query elements using a range of filters (ID, type, text content, style, tag, attributes, component name, and slot), delete elements from the canvas, and reposition elements relative to an anchor without deleting and recreating them.

The element builder now supports a much broader set of element types, including rich text, form elements, media embeds, tabs, sliders, CMS collections, page slots, and dropdowns.

Comments

Agents can now read and add site comments: listing threads and replies, replying to threads, and looking up workspace users by email.

Comments at the element level are also now supported.

CMS

Agents can now unpublish CMS items.

Mode awareness

Agents now understand which Designer mode the user is in.

The current mode is exposed in tool responses, ModeForbidden errors are surfaced clearly, and tool descriptions include mode constraints to prevent unnecessary failures.

Guide content has been updated for Build mode workflows.

MCP resources

The MCP server now supports MCP resources.

In supported clients such as Claude and Cursor, you can @-reference resources directly without calling a tool first.

The Webflow Guide is now available as a resource.

Version 1.3 of the Webflow MCP server adds over 30 new tools and actions across component authoring, branch management, styles, elements, and comments.

If you are already using the MCP server, your agents and prompts automatically use this version.

To start using the MCP server, see Getting started.

Original source

The Data API now exposes endpoints for managing the JSON-LD schema markup attached to a page.

Schema markup powers rich search results such as FAQ snippets, breadcrumbs, organization cards, and product listings.

Previously, schema markup could be edited only one page at a time in the Designer.

New endpoints

All four endpoints are available under the /v2/beta/ prefix.

Method Path Required scope GET /pages/{page_id}/schema-markup pages:read PUT /pages/{page_id}/schema-markup pages:write POST /sites/{site_id}/pages/schema-markup/query pages:read PATCH /sites/{site_id}/pages/schema-markup pages:write

Locale-aware reads and writes

Each endpoint accepts an optional localeId to target a secondary locale.

When a secondary locale has no schema markup of its own, the response returns the primary locale's schema markup and sets isInherited to true.

Bulk operations

The bulk read endpoint accepts up to 100 page entries per request.

The bulk update endpoint accepts up to 25 page entries per request.

Each entry in a bulk request can target a different locale, so you can update the same page across multiple locales in a single call.

Flexible input

The jsonLdSchema field accepts a JSON object, a raw JSON string, or a string wrapped in a <script type="application/ld+json"> tag.

Pass null to clear the schema markup for the targeted page or locale.

Validation limits

Each entry is validated against the following limits:

• 60KB raw input
• 32 levels of nesting
• 5,000 nodes

Original source