DevLink Export

DevLink is described in the documentation as the bridge between design and code for teams working in Webflow. It covers three jobs, and this page covers only one of them:

Export is a one-way flow from Webflow to code. The components are designed visually in the Designer; a command in the terminal turns them into plain React files; the application imports those files like any other module. Nothing flows back: editing an exported file never changes the Webflow site, and the next export overwrites the edit. The design system stays in Webflow, and the application owns everything else.

The documented use cases are prototyping in Webflow and exporting to React for further development, keeping an application visually consistent with a Webflow site, and smoother hand-offs between designers and developers.

Source: DevLink: Overview

Source: DevLink export setup

The exported output is plain React, so it is not tied to Next.js. The quickstart uses Next.js and states that any React-based framework works. The framework guides cover the App Router and the Pages Router of Next.js, Remix and Gatsby, and a Vite or Create React App project follows the same pattern of importing one stylesheet and wrapping the root in one provider.

Source: DevLink export quickstart

The export is a pipeline with a fixed order. The CLI reads the configuration, authenticates, fetches the site’s components and styles from Webflow, filters them with the components and componentGroups rules, generates React files, stylesheets and engine modules into the root directory, and prints warnings for anything that could not be exported as written.

The dotted edge is the maintenance loop. Whenever the designer changes a Component, the developer or a CI job runs the export again, reviews the diff of the webflow folder and commits it. Because the folder is generated, the review looks at what changed in the design, not at hand-written code.

The documented workflow in five steps is: design the styles, variables and Components in Webflow; configure the connection between the project and the React application; export with the CLI; import the global styles and the generated components; add functionality such as logic, state and interactivity in the application.

Source: DevLink: Component export

DevLink exports Components, not arbitrary canvas elements. A selection that is not a Component does not appear in the export, and the quickstart’s troubleshooting list starts with that check. To convert elements, select an element or a group of elements, right-click, choose Create Component and give it a descriptive name, because the name becomes the React component name.

For Fernbrook Gardens the designer prepares the following Components in the Designer, using the techniques of Building a Design System:

The rules of the guidelines that matter most at this stage are these. Keep a Component self-contained: everything it needs for its look must live inside it, because page-level and site-level custom code is not exported. Expose every value the application must change as a prop instead of relying on text edited in the application. Name Components, props and variants with plain words, because the names are sanitized on export (see Name-change rules and @warning tags).

Source: DevLink export quickstart

The kiosk is a new Next.js application. The quickstart creates it with create-next-app and installs the CLI as a development dependency so that every contributor and every CI run uses the version recorded in package.json.

Source: DevLink export quickstart

The documentation installs the latest tag; pinning an exact version is the safer choice for a repository, in line with the guidance in Webflow CLI, because a pipeline that silently changes its tool version is hard to debug. The CLI can also be installed globally so that webflow works outside any project.

Then, from the root of the React project, run the export:

Source: DevLink export quickstart

On the first run the CLI opens the browser to authenticate, then walks through the setup questions: which site, which root directory, which components and groups, whether to generate TypeScript and whether to use CSS scopes. Accepting the defaults exports every component to ./webflow with style isolation enabled. The answers are saved to webflow.json, so later runs do not prompt again. The result is a populated webflow folder with the React components, the generated stylesheets, a DevLinkProvider and the supporting modules the components depend on.

After the run, check the output for @warning tags. They mark an identifier that DevLink could not export as written (see Name-change rules and @warning tags).

The configuration lives in webflow.json in the project root. The siteId is at the top level and every other option is under a devlink-export object. The older .webflowrc.js file is deprecated, and existing projects should move to webflow.json.

Source: DevLink export setup

Source: DevLink export setup

The command resolves its credentials and its site in a fixed order. This is the same model as the rest of the CLI, described in Webflow CLI.

Source: Webflow CLI: Command reference

For daily work the browser login is enough. For a script or a pipeline use a token and keep it out of the command line, because a flag value shows in the process list and in shell history:

Source: DevLink export quickstart

When authentication fails, the documentation lists these checks: the token has the right permissions; the token can access the site ID in webflow.json (a Site token covers one site, a Workspace token covers every site in the workspace); the environment variables are loaded; webflow.json is in the application’s root directory. A forced fresh login is webflow auth login --force.

The export writes React files into the root directory, by default a webflow folder at the project root. The structure, as documented for the React output, is the following.

Source: DevLink export reference

Components that belong to groups or libraries are exported into group and library folders, which can nest groups. The folder names in the listing above are the ones the documentation names; the exact file list depends on the site, for example the IX3 engine files are lightweight stubs on a site that has no GSAP interactions, so that bundlers still resolve their imports.

css/global.css is the single stylesheet the application imports, once, at the root. It uses @import and @layer to pull in the category files, so the order and the cascade are the same on every export. It contains:

variables.css holds the CSS custom properties that come from the site’s Webflow variables, plus the base typography and link styles. This is why a variable collection such as Fernbrook’s brand collection, described in Variables and Modes, is a design-token source for code as well: the kiosk can read the exported custom properties in its own stylesheets and stay in step with the website.

The breakpoints are the Webflow defaults, with the cascade of Responsive Design and Breakpoints: styles set at the base breakpoint apply to smaller screens until a smaller breakpoint overrides them. A kiosk is a fixed touch screen, so most of its layout comes from the application, and the components should be tested at the breakpoint that matches the screen’s width.

Source: DevLink export reference

DevLinkProvider is the runtime wiring. It sets up both interaction engines, Classic Interactions (IX2) and Interactions with GSAP (IX3), so there is no separate provider for GSAP. The quickstart wraps the app in it whenever the components use interactions. ix3-interactions.tsx exposes the useIX3Interactions hook and an IX3Provider, and DevLinkProvider nests that provider automatically, so the application never imports the file directly.

DevLinkFontTags is a server-rendered component that loads the external fonts. Placed in the document head it avoids a brief flash of a fallback font. If the site uses no external fonts it returns null, at no cost. Without it, fonts still load through client-side injection, but the fallback font may flash.

The root layout of the kiosk, in the Next.js App Router, imports the global stylesheet, renders the font tags and wraps the children in the provider:

Source: DevLink export quickstart

The import of DevLinkFontTags follows the documented location in webflow_modules; the quickstart’s own listing uses a relative path, so the path depends on where the layout sits relative to the export folder. The path alias below makes the import independent of the file’s depth. The lang attribute stays an application decision; the kiosk’s Spanish and German variants are handled by the application, not by the export.

The alias goes into the paths section of tsconfig.json:

Source: DevLink export quickstart

With the alias, import { PlantCard } from "webflow/PlantCard" resolves to ./webflow/PlantCard from anywhere in the application. A Next.js project created with the default template already has an alias for its own src folder, and the webflow/* entry is added beside it; make sure the include list of tsconfig.json covers the export directory.

Webflow’s generated CSS is global by nature: classes such as w-nav and base rules for body and headings apply everywhere. Dropping them into an application would restyle the application’s own pages. CSS scopes prevent that.

When cssScopes is enabled, which is the default and the recommended setting:

The practical consequences are the following. A kiosk header written by hand next to an exported SiteHeader keeps its own typography. A Tailwind or CSS Modules stylesheet in the application does not collide with the w- utility classes. Because the wrapper is display: contents, it does not break flex or grid layouts in the application, but it does appear in the DOM, so a CSS selector in the application that depends on direct children, such as .grid > *, now sees the wrapper instead of the component’s root. If cssScopes is false, Webflow rules apply globally and the only protection is discipline, so it is only advisable for an application that is entirely made of exported components.

Source: DevLink export reference

The older sync-based DevLink used CSS Modules for the same purpose, through a cssModules option; export replaced it with cssScopes. See Migrating from devlink sync.

Names in Webflow are free text, and names in React are not. The export sanitizes them, so the identifiers an application uses are sometimes different from the ones a designer typed.

Source: DevLink export reference

When an attribute is filtered, except for an empty name, the CLI prints a warning and the generated component gets a JSDoc @warning block. The block says the component could not be fully exported and lists each removed attribute, for example an invalid onClick. The attribute is removed from the rendered JSX. This is why the quickstart tells the developer to look for @warning tags after every export: a custom attribute on an element can silently disappear from the output.

For Fernbrook Gardens the designer follows three habits that keep names stable: Components get plain two-word names such as PlantCard; props get short names such as plantName and zoneLabel; and event handlers are never added as custom attributes in the Designer, because they would be filtered. Handlers are passed from the application through an Attributes prop instead (see the next section).

DevLink converts the properties of a Webflow Component into typed React props, with the defaults and rules set in Webflow. The Type setting of a property controls which values it accepts and how it appears in the Designer.

Style Variants, the compact and feature versions of PlantCard, are exported as a variant prop whose values are the variant names. Conditional visibility rules that are driven by a variant compile to React as well.

Source: DevLink export setup

The strings are exactly the Webflow variant names unless camelCaseVariantNames is on. A designer who renames a variant therefore changes an API: the application must be updated in the same pull request that commits the new export. Treat variant names like exported function names.

Forms follow two build paths in the guidelines. A full Webflow form can be exported as one Component, and the application attaches handlers through an Attributes prop. The exported form is uncontrolled: the handler prevents the default submission, reads the values with FormData and posts them to the application’s endpoint. If the handler throws, the form shows its Error state; otherwise it shows its Success state. Alternatively, individual inputs and buttons are exported and composed inside a hand-written form element, which gives full control over validation, error messages and submission state.

The kiosk has a small "tell us about this plant" form. The designer builds it as a Component named PlantFeedbackForm with an Attributes prop on the form element:

Source: DevLink: Component architecture

Note that exported forms do not submit to Webflow. The submission handling, spam protection and storage that Forms describes for a published Webflow site belong to Webflow’s hosting; in the exported component the application is responsible for them, so the /api/feedback route in the example is the application’s own code.

DevLink export supports both interaction engines. Classic Interactions (IX2) are the original engine, described in Classic Interactions. Interactions with GSAP (IX3) are the GSAP-powered engine with timelines and plugins such as ScrollTrigger, SplitText and CustomEase, described in Interactions with GSAP. To enable either, wrap the application in DevLinkProvider.

Source: DevLink: Interactions

The component architecture guidelines distinguish two approaches, which can be mixed. Complex components are self-contained sections or features that should look and behave the same in Webflow and in the application, such as navigation bars, pricing tables, footers, heroes or feature blocks. Atomic components are small building blocks of a design system, such as buttons with variants, headings of several sizes, links with different styles or cards with different layouts. Fernbrook uses atomic components for PlantCard and the badge inside it, and a complex component for SiteHeader.

The quickstart’s structure for a Next.js app is: export into webflow, add the path alias, import global.css and wrap the root in DevLinkProvider, then use the components in pages. The framework guides add details that matter in production.

Source: DevLink: Framework guides

A kiosk page for Fernbrook Gardens then reads as follows, with the plants loaded on the server and the cards rendered by exported components:

Source: DevLink export quickstart

The endpoint in the example is the garden’s own placeholder API and not a Webflow endpoint. Because interactions and the provider rely on the browser, check that the page’s tree still hydrates cleanly after adding exported components.

The designer changes a Component and the application must follow. The loop is short and deliberately mechanical:

Source: DevLink export quickstart

Committing the webflow folder is the common choice: builds are then reproducible without Webflow credentials, a reviewer sees every design change as a diff and a rollback is a git revert. The alternative is to run the export in the build, which always yields the latest design but makes every build depend on the Webflow API and on a token, and means a designer’s edit can change a production build without a code review. Fernbrook commits the folder and refreshes it through a scheduled pull request, as the next section shows.

Pass WEBFLOW_API_TOKEN in the environment and add --no-input, which disables every prompt for CI. The CLI also turns prompts off when it detects a non-interactive environment, and --no-input makes the intention explicit. The token is a Workspace or Site API token stored as a repository secret.

The following GitHub Actions workflow refreshes the export every weekday morning and opens a pull request when the generated folder changed. The siteId comes from the committed webflow.json.

Source: DevLink export quickstart

Three details make the job dependable. The CLI is installed from package.json, so the version is the pinned one and npm ci is reproducible. The token is read from the environment and never appears in the command, so it is masked in the log. The job opens a pull request instead of committing to the main branch, so a designer’s change is reviewed together with its effect on the application’s tests, and a failed export, for example from an expired token, makes the job fail visibly. The general CI guidance, such as secrets and exit codes, is in Webflow CLI, and a broader pipeline that also covers tests and other Webflow deployments is in Testing, CI and DevOps.

The earlier DevLink workflow used webflow devlink sync with a devlink block in the configuration. The command is deprecated and was removed from the CLI, and devlink export replaces it. The migration is mechanical, and the documentation lists the steps.

Older books and tutorials, including the book Webflow by Example that this sub-section uses as a reference point for the classic workflow, were written before component export and describe the Designer, the CMS and Classic interactions, not DevLink. Tutorials found online that use webflow devlink sync, a devlink block, a ./devlink folder or WEBFLOW_SITE_API_TOKEN describe the removed workflow, and following them on a current CLI fails or produces a configuration that is silently ignored. The list of such outdated advice is collected in Where Older Books and Tutorials Are Outdated, and the dated changes in Product Changes and Deprecations.

Use DevLink export when a design system lives in Webflow and an application must render the same components with its own routing and data: a kiosk, a customer portal, a documentation site, or a Next.js application that mixes marketing components with product screens. Prefer code export for a static snapshot of a whole site, a headless approach with the Content Delivery API when only the content is needed and the design is built in code, and code components when the direction is the opposite, React written by developers and used by designers on the canvas. The related pages are Code Export and Portability, Hybrid Apps, Code Components and Reverse Proxy and Custom Hosting, which covers serving an application next to a Webflow site on one domain. Webflow also offers a DevLink template in its Made in Webflow gallery that comes with components and styles already prepared for export.

Source: Made in Webflow: DevLink template