Webflow Developers Updates & Release Notes

Get page content's translatable parameter previously only checked whether a page's entire canvas was excluded from translation. A component instance's overridden property values were always returned as-is, even when the specific property was excluded — inconsistent with get component properties, which already filtered properties individually.

translatable now filters component property overrides the same way: an overridden value is omitted from a component instance's propertyOverrides if that property is excluded from translation for the requested locale. If a component instance's overrides are all excluded, the instance is omitted from the response entirely. A component instance with no overrides at all is unaffected.

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

Global telemetry configuration

v2.5.0 changes where telemetry preferences are stored and fixes a crash affecting sites that combine code components from different sources.

webflow auth telemetry --enable/--disable now writes to a global config file (~/.config/webflow/telemetry.json on macOS/Linux, %APPDATA%\webflow\telemetry.json on Windows) instead of the current project's webflow.json. Bare CLI invocations in a project without a manifest no longer create one just to record a telemetry preference.

A new --local flag opts back into the previous behavior for teams that want a per-project override:

webflow auth telemetry --disable --local

A webflow.json that already has a telemetry setting continues to be read and takes precedence over the global config for commands run in that directory. DO_NOT_TRACK continues to override everything.

Fix: crash when combining code components from different sources

Fixed a crash — Element type is invalid: expected a string ... but got: object — that could occur when a published page loaded code components built against different React major versions. Upgrade @webflow/react to 2.1.1 and re-bundle libraries to pick up the fix.

Also in this release

Patched transitive brace-expansion and PostCSS dependencies addressing known vulnerabilities.

webflow cloud deploy can now resolve its framework builder from a shared @webflow/app package when enabled server-side; the local COSMIC_BUILD_ENGINE=v2|legacy environment variable can override the selection for a single run.

Upgrading

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

A clearer review scope

Over the past several weeks we've updated the Marketplace Guidelines, the app review process, and the tools available to you before you submit. Here's what changed and what to expect next.

App review now focuses on the surfaces Webflow is responsible for: code that runs in the Webflow Designer, your app's interactions with Webflow's APIs, and how your app handles Webflow credentials and Webflow user data. How your app's code behaves on your customer's published site is part of your service relationship with your customer. The new Review scope section in the guidelines states this directly.

What this means in practice:

Published-site code practices are now recommendations, not review gates. Subresource integrity, immutable script URLs, page-scoped injection, additive-only page changes, and similar practices moved to Recommended practices for published-site code. We still recommend all of them — your customers will hold you to them — but review won't reject your app over them.

Three gates remain for code you deliver to customer sites: deliver it through the Custom Code API, disclose what it does in your listing and submission, and remove your registered Custom Code on uninstall.

One consolidated backend rule: no untrusted origin may read or mutate a Webflow-authenticated response or state. Review verifies this by probing your live endpoints — not by auditing your backend source.

Data Client apps attest instead of being audited: provide three written attestations at submission — your app's Webflow OAuth token is encrypted at rest, stored server-side only, and deleted on uninstall or revocation.

Updated docs and guidelines

We revised the Marketplace Guidelines and app submission docs, including:

• Expanded review criteria in the Marketplace Guidelines, organized into linkable rule groups
• Corrected guidance on installation scopes — configured scopes your app doesn't use should be removed
• Reworked guidance for app-delivered code — the three gates above, plus recommended practices for published-site code; Designer Extensions still interact with the user's site exclusively through the Designer APIs
• Documented submission artifacts — a published testing site, source maps with the package manifest and lockfile for compiled bundles, production bundles free of debug routes and staging residue, and the optional preflight receipt
• Listing language requirements — English listings, with disclosure for non-English product experiences

Reviews check exactly what's published here

Our internal review checklist was rewritten to mirror the public docs. If a requirement isn't published on developers.webflow.com, we don't hold your submission to it. The docs you can read are the same standard we review against.

Every submission is reviewed against current guidelines — including updates

When you submit an update to an already-published app (including bug-fix releases), it's reviewed against the guidelines as they stand today, not as they stood when your app was first approved. If your app was approved before a guideline existed, an update may surface findings that are new to you. Published apps are not being retroactively delisted — your live listing is unaffected until you submit an update, and when findings come up, the review feedback will tell you exactly what to fix.

Clearer review feedback

Review outcome emails now list each required change explicitly, with links to the relevant docs, and distinguish required changes from suggestions.

Pre-submission checks you can run yourself

The app submission form now offers a downloadable skill toolkit — two agent skills for the app lifecycle:

• webflow-app-preflight checks your app and bundle against the review gates and the recommended practices — development builds, custom-code cleanup, scope mismatches, backend authorization, and listing assets — and ends in a clear go/no-go before you submit.
• webflow-app-review-remediation helps you work through review findings and prepare a resubmission after you've received feedback.

A skill is a folder with a SKILL.md instruction file that AI coding agents load as step-by-step expert guidance. It's an open, plain-Markdown format — you can also just read it. To use the skills:

• Claude Code: unzip and copy each skill folder into .claude/skills/ in your project (or ~/.claude/skills/ to use them everywhere), then run /webflow-app-preflight or ask Claude to preflight your app.
• Claude apps (claude.ai and desktop): upload a skill as a zip under Settings → Capabilities → Skills, then ask Claude to run it.
• Codex CLI: copy the skill folders into ~/.codex/skills, then ask Codex to run the preflight.
• Other agents: any agent that supports the open SKILL.md format can load them — or paste the SKILL.md contents directly into your agent's chat.

What's coming

In the coming weeks we're adding automated guideline checks at submission. Submissions with guideline failures can be rejected on that basis. The preflight skill isn't required — but it checks for the same kinds of issues, so running it before you submit is the easiest way to avoid a rejection. If your app has been live for a while, we recommend reviewing the current guidelines before your next update so nothing catches you by surprise.

Questions

Open a ticket at support.webflow.com — support tickets are the reliable path to the Marketplace team.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.