This is an overview of the changes to the Webflow APIs and related tools. To filter the list, select one or more tags.

Updates to DevLink Export

DevLink Export ships a major upgrade. A new webflow devlink export command replaces webflow devlink sync and walks you through setup the first time you run it. Exported components are fully-typed TSX by default, and the generated CSS is now isolated to your DevLink components via CSS @scope so it won’t leak into the rest of your app. Webflow’s native Slot element replaces DevLink Slots (with an in-canvas Convert action), and the new Attributes prop replaces Runtime Props (auto-conversion coming soon).

DevLink Export requires @webflow/webflow-cli v1.19.0 or later, on Node.js v22+.

New export workflow

  • New webflow devlink export command replaces webflow devlink sync. See Quickstart: DevLink Export.
  • The first run walks you through an interactive setup and saves your settings to webflow.json, so subsequent runs — manual or in CI — execute without prompts.
  • New components and componentGroups regex filters in webflow.json let you scope the export to a subset of your library. See Configuration options.
  • The webflow devlink export command now requires the DevLink Export read permission on OAuth and Site API tokens.

TypeScript by default

  • Exported components ship as fully-typed .tsx files with JSDoc comments. Set ts: false in webflow.json to opt out and emit .jsx instead.

Style isolation and CSS structure

  • New cssScopes option (enabled by default) wraps the exported styles in a CSS @scope rule tied to each component’s wrapper, so DevLink styles can’t leak into the rest of your app.
  • Categorized CSS files (normalize, defaults, variables, tags, classes, fonts) are imported from a single global.css you load once at your app root.

New Designer primitives

  • DevLink Export now supports Webflow’s native Slot element — the recommended replacement for DevLink Slots. Existing DevLink Slots continue to work but show a deprecation warning in the Designer; use the in-canvas Convert action to migrate. See Slots.
  • DevLink Export now supports the new Attributes prop — the recommended replacement for Runtime Props. Existing Runtime Props will be automatically converted soon. See Attributes.
  • New supported elements: Iframe, Inline Code, and Code Block. See Supported elements.

Broader component coverage

  • Nested components and any library components they depend on are automatically included in the export.
  • Conditional visibility settings on elements are compiled into the exported React code (Boolean, Enum, Number, Text, and Style Variant conditions).

Defaults and cleanup

  • The default export folder is now webflow/ at the root of the project (was devlink/).
  • The following options are no longer supported: cssModules, skipTagSelectors, envVariables, overwriteModule, fileExtensions.

Migration

Existing DevLink Sync projects can upgrade by following the Migrating to DevLink Export guide. It walks through the CLI bump, .env rename, webflow.json restructure, tsconfig and import-path updates, and the Designer-side migration of Runtime Props and DevLink Slots.


v1.18.0: Sites commands and sort controls

v1.18.0 adds a new sites command group for managing Webflow sites from the CLI, plus --sort-by and --order flags for assets list and cms collections list.

Sites commands

A new webflow sites command group lets you list, inspect, and publish sites without leaving the terminal.

  • sites list — List all sites in your workspace. Supports --fields to choose which columns to display and --json for machine-readable output.
  • sites get <siteId> — Get details for a specific site, including display name, short name, time zone, and publish timestamps.
  • sites domains --site <siteId> — List the custom domains configured for a site.
  • sites publish --site <siteId> — Publish a site to the Webflow subdomain or to specific custom domains. Supports --page <pageId> to publish a single page and --dry-run to preview what would be published without triggering a build.

Sort flags for assets and CMS

assets list and cms collections list now accept --sort-by and --order flags so you can control how results are returned.

  • assets list supports --sort-by displayName | originalFileName | contentType | size | lastUpdated and --order asc | desc (default: asc).
  • cms collections list supports --sort-by displayName | slug | lastUpdated and --order asc | desc (default: asc).
  • The site picker now defaults to alphabetical order by display name.
  • Invalid flag values produce a clear error message listing the valid options.

DevLink global stylesheet moves into the css/ subfolder

When you re-sync your site with DevLink, the global.css stylesheet is now written to the css/ subfolder alongside the other DevLink stylesheets instead of at the root of the export.

What changed

global.css now lives at css/global.css alongside classes.module.css, instead of at the root of <rootDir>.

<rootDir>/ ← Root folder defined in `webflow.json`
├── DevLinkProvider.jsx
├── DevLinkProvider.d.ts
├── css/
│ ├── global.css ← Moved from the root of <rootDir>
│ └── classes.module.css
├── <UserComponent>.jsx
└── webflow_modules/

Action required

Update the path in the file that imports global.css (usually a layout or entry file) to add the css/ segment.

Before:

1import "devlink/global.css";

After:

1import "devlink/css/global.css";

The same change applies if you use a different alias or relative path — add css/ before global.css.

For more information, see What DevLink Exports.


v1.17.0: Asset management commands

v1.17.0 adds a new assets command group for managing your Webflow site assets directly from the command line, along with an improved site selection experience and a CMS display fix.

New webflow assets commands

You can now list, upload, update, and organize assets without leaving your terminal.

List assets for a site:

$webflow assets list --site <siteId>
$webflow assets list --site <siteId> --folder <folderId>
$webflow assets list --site <siteId> --json
$webflow assets list --site <siteId> --fields id,displayName,size

Upload a file as an asset:

$webflow assets upload ./hero.png --site <siteId>
$webflow assets upload ./hero.png --site <siteId> --name "Hero Image" --folder <folderId>
$webflow assets upload ./hero.png --site <siteId> --dry-run

Supported file types: png, jpg, jpeg, gif, svg, webp, avif (≤ 4 MB); pdf, doc, docx, xls, xlsx, ppt, pptx, txt, csv, odt, ods, odp, json, lottie (≤ 10 MB).

Update asset metadata:

$webflow assets update <assetId> --alt-text "A hero image"
$webflow assets update <assetId> --display-name "New Name"
$webflow assets update <assetId> --alt-text "..." --dry-run

Manage asset folders:

$webflow assets folders list --site <siteId>
$webflow assets folders create "Marketing" --site <siteId>
$webflow assets folders create "Q2 Campaign" --site <siteId> --parent <parentFolderId>

Improved site selection

The site selection prompt now uses a searchable list sorted by most recently updated, with site slugs shown alongside display names to help disambiguate sites with similar names.

CMS list alignment fix

Column headers in webflow cms list output now line up correctly with data rows.


Google Fonts and Adobe Fonts now ship with DevLink Export

DevLink Export now automatically loads Google Fonts and Adobe Fonts at runtime, matching how a published Webflow site renders them.

What changed

  • fonts.manifest.json — a new file in every export, listing the Google Fonts families and Adobe Fonts kit ID in use on your site.
  • useInjectFonts hook — a new hook that reads fonts.manifest.json on mount and injects the WebFont Loader and the Adobe kit scripts into document.head.
  • DevLinkProvider.tsx — now calls useInjectFonts, so mounting the provider is enough to load both font families.

Custom uploaded fonts continue to ship as @font-face rules in css/fonts.css and are unaffected.

Action required

If your site uses Adobe Fonts, you need to add your deployment domains to your Adobe Fonts web project allowlist before fonts will render outside *.webflow.io. Google Fonts requires no setup.

Run webflow devlink sync to pick up the changes. For full details, see Fonts in DevLink Export.


DevLink engine file structure update

When you re-export your site with DevLink, you’ll see updated import paths in your exported components. Your components should continue to work without any code changes on your part.

What you’ll see after re-exporting

Updated import paths

Your exported components will have updated import paths for built-in Webflow elements:

Before:

1import Block from "../_Builtin/Block";

After:

1import Block from "../webflow_modules/Basic/components/Block";

Import paths have changed from ../_Builtin/Block to ../webflow_modules/Basic/components/Block, but your component code remains exactly the same.

Deprecated barrel export removed

The deprecated index.js barrel export file has been removed. This file previously re-exported all DevLink modules with a performance warning.

If you were importing from index.js, you’ll need to update your imports to use specific file paths instead.

Your components still work

No component code changes required — your component code, props, and behavior remain exactly the same

Same export format — component and global CSS file structure is unchanged

Easy update — simply run webflow devlink sync to update your components with the new structure

What changed internally

DevLink engine files have been reorganized from a flat structure into organized folders:

  • All internal components moved to webflow_modules/ folder
  • Components grouped by category (Dropdown, Form, Navbar, etc.)
  • Helper functions grouped with their related components

⚠️ If you’ve customized or directly imported DevLink internal files, you may need to update your code.

Recommendation: Avoid importing DevLink internal files directly. If you do, be aware that these files are not part of the external API and are subject to breaking changes with future updates.

For more information, see What DevLink Exports.


April 15, 2026

Comments API: replies, user search, and webhook enrichment

Three additions to the Comments API that enable integrations to participate in comment threads and build richer comment notifications.

New endpoint: Create comment reply

The Create Comment Reply endpoint lets you post a reply to an existing comment thread programmatically.

  • Method: POST /beta/sites/{site_id}/comments/{comment_thread_id}/replies
  • Scope: comments:write
  • Author attribution: The reply is always attributed to the user who authorized the OAuth token.
  • Mentions: To @mention a user in a reply, include their user ID in double square brackets in the content, field such as [[userId]]. Use the new Search Users by Email endpoint to look up user IDs.

Creating a reply automatically fires the comment_created webhook.

New endpoint: Search users by email

The Search Users by Email endpoint lets you look up a workspace user by their exact email address, returning their Webflow user ID for use in comment @mentions.

  • Method: GET /beta/sites/{site_id}/comments/users?email={email}
  • Scope: comments:read
  • Search type: Exact email match only — no partial or fuzzy search.
  • Returns an empty array if no user with the specified email address is found.

Webhook enrichment: comment location data

The comment_created webhook payload now includes three new fields that identify where a comment is anchored on a page.

FieldTypeDescription
objectIdstringThe ID of the page or CMS collection item the comment is on
objectTypepage | cms-itemWhether the comment is on a page or a CMS item
elementIdstringThe ID of the DOM element the comment pin is attached to

The existing pageId field is unchanged; it always contains the containing page ID. For comments on CMS items, objectId is the item ID, while pageId is the template page.

These fields are additive. Existing webhook consumers are not affected.



Publishing individual pages

You can now publish an individual page instead of the entire site.

By default, the Publish Site endpoint continues to publish the entire site. However, you can now pass the ID of a single page in the pageId parameter to publish only that page.

In the case of publishing an individual page, the API publishes:

  • The HTML, JSON, and CSS for the selected pages
  • All locales for the selected pages
  • Page-specific JavaScript for the selected pages
  • An updated static manifest that includes the new or updated pages
  • An updates sitemap that includes the selected pages
  • And updates manifest.json file to support detail pages (collection templates)

Global resources that have changed since last publish continue to show the version that was on the page in the Designer when the page was published.

Example

To publish an individual page, include the ID of the page to publish:

$curl -X POST https://api.webflow.com/v2/sites/{site_id}/publish \
> -H "Authorization: Bearer <token>" \
> -H "Content-Type: application/json" \
> -d '{
> "customDomains": ["660c6449dd97ebc7346ac629"],
> "publishToWebflowSubdomain": true,
> "pageId": "64abc123def4567890abcde1"
> }'

To publish the full site as usual, omit pageId:

$curl -X POST https://api.webflow.com/v2/sites/{site_id}/publish \
> -H "Authorization: Bearer <token>" \
> -H "Content-Type: application/json" \
> -d '{
> "customDomains": ["660c6449dd97ebc7346ac629"],
> "publishToWebflowSubdomain": true
> }'

The response now includes a publishScope field to indicate whether the site or an individual page was published:

1{
2 "customDomains": [],
3 "publishToWebflowSubdomain": true,
4 "publishScope": "page"
5}

Webhooks

The Site Publish webhook event has a new publishScope field, which shows site if the entire site was published and page if an individual page was published. If this field is set to page, the pageId field shows the ID of the page.


MCP v1.2 - Elements, styles, variables, and more

Version 1.2 of the Webflow MCP server adds new element tools, expanded CSS coverage, full variable management, webhook support, and MCP Bridge App improvements. If you are already using the MCP server, your agents and prompts automatically use this new version.

Elements

  • Create more complex elements: Previously, the element builder could create nested elements only 3 levels deep, but now it can construct arbitrarily deep element trees in a single call. In addition, execution is faster and more element types are supported.

  • Before/after placement: Agents can now place elements before and after existing elements, giving them more precise control over where elements are inserted relative to their siblings.

  • Create elements from raw HTML: A new tool accepts a raw HTML string and converts it directly to Webflow elements.

  • Element query: A new query tool lets agents search and filter elements by type, class, tag, or attribute. Results are returned as a structured tree, not a flat array.

  • Cleaner get_all_elements response: The response is now a hierarchical tree with only essential data per node, reducing payload size.

  • Child depth control on get_selected_element: Agents can now control the number of levels of children returned when they retrieve an element by providing the depth parameter.

  • remove_element: Agents can now delete elements from the canvas.

Components

  • Component editor with slot support: A new component editor supports no depth limit and slot definition on edit, mirroring the capabilities of the updated element builder.

  • unregister_component: Agents can now remove a component from a site. The tool returns a clear error when the component does not exist or has active instances.

  • Read component instance slots: Agents can now read all slots defined on a component instance.

Styles

  • 500+ CSS properties: The Style tool now covers 500+ CSS properties. Properties that were previously unsupported no longer fail silently.

  • Improved style search: Style search now supports filtering by property, value, tag, and class name, returning more relevant results with less noise.

  • remove_style: Agents can now delete a style from a site. The tool returns a clear error when the style does not exist or is currently in use.

Variables

  • Custom variable creation: Agents can now create custom variables, including support for color-mix() and calc() expressions.

  • Read custom variables: Agents can now read all custom variables defined on a site, including their expressions and resolved values.

  • Search variables: A new search action on the Variable tool lets agents filter variables by name, type, or collection ID.

  • Rename and delete variables: Agents can now rename or delete variables. The tool returns a clear error when the variable does not exist or is currently in use.

Webhooks

  • data_webhook_tool: A new tool covers webhook management, including creating and deleting registrations for specific event trigger types.

Enterprise

  • list_site_activity: A new action on the Enterprise tool lets agents query site activity logs.

MCP Bridge App

  • Improved UI and observability: The MCP Bridge App now surfaces tool execution stages, status, and timing in real time. Agents and engineers can view tool arguments and responses, export logs, and access quick links for common debugging actions.

  • Improved heartbeat: The heartbeat interval is reduced to prevent premature timeouts. Agents are notified on connection loss and can reconnect without losing state.

Bug fixes

  • Asset: corrupt asset silent failure: Tools that accept asset IDs now return a clear error when the asset does not exist, instead of failing silently. This update applies across all tools.

  • CMS: locale ID required error: Fixed an error where the CMS tool incorrectly required a locale ID in contexts where it was not needed.

  • Site: custom domain required error on publish: Fixed an error where publishing failed when no custom domain was set on the site.

  • Styles: combo class creation bug: Creating a combo class when the base class already exists no longer fails. This behavior now matches the expected in-product behavior.

Resources