Webflow Developers Updates & Release Notes

The Get Site Plan endpoint now returns the site's hosting plan consistently. This is a breaking change for any code that compares id or displayName against the previous values.

Starter sites

Sites without a paid hosting plan used to return the Starter workspace plan. They now return the Starter hosting plan.

Field

Before

After

id

workspace-starter-seat-v1

hosting-starter-v1

displayName

Starter Workspace

Starter

Public plan names

displayName now returns the public plan name instead of the internal invoice name. As a result, the names of some plans change. For example, Basic Hosting (circa 2016) is now Basic Hosting, and Enterprise is now Enterprise Hosting.

The AEO Analytics API (beta) lets you read how AI bots visit your site, and how answer engines mention and cite you. AEO, or answer engine optimization, is the practice of improving how your content appears in AI-generated answers. It works with sites that have the AEO analytics entitlement.

Bot traffic

• Get Bot Traffic — total requests from the AI bots Webflow tracks, by provider or category
• Get Bot Traffic by Page — the pages and files bots requested most

Prompts

• List Prompts — your tracked prompts, with each one's topic and status
• List Prompt Executions — answer engine responses to your prompts, with their mentions and citations
• Get Prompt Execution — one response, including its full text

Visibility

• Get Visibility Score — the share of responses that mention your organization
• Get Visibility Score Breakdown — the visibility score for each topic or prompt

Citations …

The Analyze API (beta) now includes three new reports and two goals endpoints.

Analyze

• Scroll depth: the scroll depth (in pixels) that 75%, 50%, and 25% of page views reached.
• Browser window height: average browser window height in CSS pixels over a time window.
• Page flow: pages visitors viewed immediately before or after a selected page, ranked by sessions, users, or page views.
• List goals: the goals configured for your site, including each goal's type, whether it's a site goal, and its integration source (HubSpot, Marketo, or Shopify).
• Goal performance: daily unique conversions for one goal, bucketed in the time zone you choose.

The Optimize API (beta) lets you read your optimizations and their results. It works with Webflow sites that have the Optimize add-on, and with non-Webflow sites that use Optimize.

Optimize

• List Optimize IDs — the optimizeId values your token can access, and the resource each one comes from
• List Optimizations — each optimization's type, status, and intervals
• Get Optimization Results — each variation's sessions, users, conversions, and conversion rate for one goal
• Get Audience Insights — the same results, split by the segments of one dimension
• Get Performance Over Time — the same results, by day or week
• List Optimization Goals — an interval's goals, and which one is the target goal
• List Dimensions — the dimensions you can group or filter reports by
• List Dimension Values — the values seen for a dimension, to use in filters …

Two new endpoint groups let you manage who has access to a Site or Workspace directly through the API, for Enterprise workspaces.

Site Access

• List Site Members — everyone with access to a Site and the role they hold
• Grant Site Access — add a Workspace Member to a Site, by email or member ID
• Update Site Member Role — change a Member's Site Role, by member ID or email
• Revoke Site Access — remove a Member's access to a Site, by member ID or email

Workspace Members

• List Workspace Members — Members and pending, declined, and expired invites
• Invite Workspace Member — invite by email, with a Workspace Role and either a default Site Role or per-Site access
• Update Workspace Member Role — change a Member's Workspace Role and default Site Role
• Remove Workspace Member — remove a Member from the Workspace …

v2.9.0 adds workspace folder placement when you import a Cloud app from GitHub, removes the leftover webflow devlink sync command, and fixes what the Server bundle's manifest lists.

Place an imported app in a workspace folder

webflow apps init --import --new accepts a new --folder-id flag that puts the new standalone app in a workspace folder at creation time:

webflow apps init --import https://github.com/<owner>/<repo> --new --folder-id <folderId>

To find a folder's ID, open the folder in the dashboard and copy the value after /folder/ in the URL. --folder-id only applies to new standalone apps, so it requires --new and can't be combined with --site-id.

Fix: Server manifest no longer lists ssr: false components

The Server bundle's wf-manifest.json (dist/Server/ssr-bundle.tar) no longer lists components whose options.ssr is false. Its components map now matches the components actually imported into Server/index.js, instead of copying the Client bundle's full CSS index. The Client wf-manifest.json and mf-manifest.json are unchanged — they still list every component, including ssr: false ones, with their CSS.

Removed: webflow devlink sync

The dead webflow devlink sync command is removed. Use webflow devlink export instead. If you're upgrading an older project, see Migrating to DevLink Export.

Upgrading

v2.9.0 adds workspace folder placement when you import a Cloud app from GitHub, removes the leftover webflow devlink sync command, and fixes what the Server bundle's manifest lists.

Place an imported app in a workspace folder

webflow apps init --import --new accepts a new --folder-id flag that puts the new standalone app in a workspace folder at creation time:

webflow apps init --import https://github.com/<owner>/<repo> --new --folder-id <folderId>

To find a folder's ID, open the folder in the dashboard and copy the value after /folder/ in the URL. --folder-id only applies to new standalone apps, so it requires --new and can't be combined with --site-id.

Fix: Server manifest no longer lists ssr: false components

The Server bundle's wf-manifest.json (dist/Server/ssr-bundle.tar) no longer lists components whose options.ssr is false. Its components map now matches the components actually imported into Server/index.js, instead of copying the Client bundle's full CSS index. The Client wf-manifest.json and mf-manifest.json are unchanged — they still list every component, including ssr: false ones, with their CSS.

Removed: webflow devlink sync

The dead webflow devlink sync command is removed. Use webflow devlink export instead. If you're upgrading an older project, see Migrating to DevLink Export.

Upgrading

MCP v2.1 widens what agents can do on the Webflow platform. Three products open to agents for the first time, branch management becomes a complete loop, CMS collections gain field groups and custom-field filtering and sorting, and agents can now generate the instructions that guide their own work. No tool or action names changed, so anything built against v2.0.1 keeps working.

New tools

MCP v2.1 introduces three new tools that open up areas of Webflow the MCP server couldn't reach before: Interactions with GSAP, Webflow Cloud, and Campaigns.

Interactions with GSAP. Agents can now bring pages to life with motion and interactivity. Interactions with GSAP is Webflow's visual animation tool, built on GSAP, the popular open source animation library, and MCP v2.1 opens it to agents for the first time. You keep complete authoring control over the result: an agent makes the first pass, and you tweak the details on the timeline and in the visual editor. Agents can now:

• Create an interaction from a complete definition, its triggers and its timelines, in a single call.
• Animate on click, hover, page load, scroll, mouse move, and custom events.
• Update an existing interaction, or remove one.
• List a site's interactions and read one with its timelines resolved. …

v2.8.0 introduces webflow apps, the new canonical command namespace for managing Webflow Cloud apps. It replaces the piecemeal webflow cloud commands with one consistent surface across the whole app lifecycle, designed so a CI job or an AI agent can drive it end-to-end without scraping human-oriented output: structured --json on read commands, --dry-run previews on every write, and predictable exit codes throughout. Reads also retry transient rate limits (429) automatically with bounded backoff, so a busy CI runner doesn't need its own retry loop.

webflow cloud init and webflow cloud deploy keep working unchanged — they now print a one-time deprecation notice pointing at the apps equivalents.

An app is standalone by default — it gets its own subdomain and isn't tied to a Webflow site. Attaching to an existing site (mounted at a path, alongside a Designer-built site) is fully supported too; it's just one additional flag away.

App lifecycle: apps init / apps deploy

# Standalone — the default. Owns its own subdomain, no Webflow site involved.
webflow apps init -n my-app -f astro --new -w <workspaceId>
webflow apps deploy -e main

Once webflow.json has an app_id, subsequent apps deploy calls need no flags at all — it's the standalone path that gets simpler over time, since there's no site or mount path to keep in sync.

apps deploy also takes --dry-run and --json, same as every other write in this namespace:

v2.8.0 introduces webflow apps, the new canonical command namespace for managing Webflow Cloud apps. It replaces the piecemeal webflow cloud commands with one consistent surface across the whole app lifecycle, designed so a CI job or an AI agent can drive it end-to-end without scraping human-oriented output: structured --json on read commands, --dry-run previews on every write, and predictable exit codes throughout. Reads also retry transient rate limits (429) automatically with bounded backoff, so a busy CI runner doesn't need its own retry loop.

webflow cloud init and webflow cloud deploy keep working unchanged — they now print a one-time deprecation notice pointing at the apps equivalents.

An app is standalone by default — it gets its own subdomain and isn't tied to a Webflow site. Attaching to an existing site (mounted at a path, alongside a Designer-built site) is fully supported too; it's just one additional flag away.

App lifecycle: apps init / apps deploy

# Standalone — the default. Owns its own subdomain, no Webflow site involved.
webflow apps init -n my-app -f astro --new -w <workspaceId>
webflow apps deploy -e main

Once webflow.json has an app_id, subsequent apps deploy calls need no flags at all — it's the standalone path that gets simpler over time, since there's no site or mount path to keep in sync.

apps deploy also takes --dry-run and --json, same as every other write in this namespace:

The Branch API (beta) is now documented for Enterprise sites with page branching enabled.

Branches

• Overview — lifecycle, async tasks, conflicts, and entitlement requirements
• List Branches — paginated branch list with computed status and nextActions
• Create Branch — enqueue branch creation from a page
• Get Branch — single branch with status
• Delete Branch — enqueue branch deletion (202 + task poll)
• Get Branch Conflicts — unresolved style and component conflicts
• Update Branch — pull main changes into a branch
• Merge Branch — merge a branch into main
• Publish Branch — publish a branch preview to its staging domain
• Get Branch Task Status — poll async branch tasks

Webhooks …

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.

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.

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

Global telemetry configuration

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. …

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.

A clearer review scope

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. …

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.

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. …