The Webflow Designer is a powerful collaborative tool for teams to design and build websites quickly and at scale. To support collaboration, the Designer offers various modes to support different aspects of the design process:
Through these features and modes, the Webflow Designer determines the specific actions a user can take to ensure teams make the right updates at the right time.
Designer Extensions extend the user’s capabilities while respecting the mode the Designer is in. Each method in the Designer API offers distinct functionality, aligning with the actions feasible in each mode. By understanding the various modes in the Designer, and how Designer APIs interact with them, you can ensure your App functions correctly across different contexts within the Webflow Designer, thus providing a seamless user experience.
Each API method’s documentation includes an “App Modes” section that outlines where and how the API can be used, as well as any limitations.
Here’s an example from the “Remove Element” method:
In this example, the “Remove Element” method can only be successfully called if the user is in design sitemode, working on the canvas in a primary locale on the main branch. If the user is in the wrong Designer mode, the API throws a ModeForbidden error. If the user lacks the required role, locale, or branch, the API throws a Forbidden error.
See below for a complete table of abilities, which defines where and how an API method can be used.
webflow.canForAppModeTo ensure your app functions correctly in the different modes of the Webflow Designer, you can leverage the webflow.canForAppMode method. This method allows you to check whether a specific action is allowed in the user’s current mode before executing it, helping to prevent errors and improve the user experience.
The webflow.canForAppMode method returns a Boolean indicating whether the specified action is permitted based on the current mode of the Designer. Here’s a basic example:
webflow.canForAppModeUse webflow.canForAppMode before any critical action that depends on the mode the user is in, such as:
See the documentation for webflow.canForAppMode for more details.
In addition to the webflow.canForAppMode() method, the Designer API provides two methods for on-demand mode detection:
webflow.getCurrentMode(): Returns the name of the current Designer mode, or null when the Designer’s internal state does not map to a public mode.webflow.isMode(): Returns a boolean that shows whether the Designer is in a specific mode.Use these methods to read the active mode on demand, such as when your extension launches or before running an action.
The Designer exposes five public modes: design, build, preview, edit, and comment.
To check a single mode without handling the full list, use webflow.isMode():
Use webflow.subscribe("currentappmode", callback) to react to mode changes in real time.
The callback fires when the user switches modes, switches branches, or switches locales, and it receives an AppModeChangeEvent object with:
mode: The new Designer mode name, or null when the internal state does not map to a public mode.appModes: The user’s current capability booleans, keyed by capability name. The same object that the webflow.canForAppMode() method returns.Callbacks that use the previous signature () => void continue to work.
The Designer API offers several patterns for mode awareness. Use this table to decide which pattern fits your extension’s needs:
When the Designer API blocks an action, it throws one of two errors:
Proactively check before acting by combining webflow.isMode() or webflow.canForAppMode() with a fallback try/catch:
For a full list of error cause tags, see the Error Handling reference.
To test out how your Designer Extension will function with Expanded App Modes, you can opt-in to the feature with your webflow.json manifest file.
Now, if you launch your Designer Extension from the Apps Panel as you normally would today, you can switch to Build mode, as an example, and your App should remain open. If you take an action via your App that a user shouldn’t be able to in that mode, you will see a ModeForbidden error thrown (or a Forbidden error when the permission gap is about role, locale, or branch), and you can catch the error appropriately to surface relevant user messaging.
We recognize that for some Apps, it may take more time to incorporate code changes to add extra error handling, UI considerations, etc. with expanded App Modes. To opt-out, set the expandedAppModes feature flag to false in your webflow.json manifest file (see below). Then, simply create a new updated app bundle with this change and submit it for review.
Opting out of expanded App Modes means your App closes automatically when the user switches away from Design mode. The App continues to run while the user is in Design mode in the primary locale on the main branch.
If you have an App using Designer v1 APIs, your app will not be able to be launched in other modes around the Designer, and will continue to only be launched when Designing in the canvas in the primary locale and main branch.