Marketplace Guidelines

Before an App can be listed in the Webflow Marketplace, it must go through our thorough review process.

Guidelines

The guidelines outlined below will be used by our review team to evaluate your submission.

Review scope

App Review checks that your App meets the baseline for the Webflow Marketplace. It does not replace your own security, privacy, compliance, and quality testing. You are responsible for the security and reliability of your entire App.

What review covers. We review your submission materials and the parts of your App that touch Webflow or Webflow users:

• Code that runs in the Webflow Designer
• Calls to Webflow APIs
• OAuth, authentication, and authorization
• Changes your App makes to Webflow data
• How your App handles Webflow credentials and user data
• Connect, disconnect, and uninstall behavior

Code on customer sites. For code your App delivers to customer sites, such as scripts added through the Custom Code API, we check how that code is delivered, disclosed, configured, updated, and removed. How your features behave on a published customer site is generally outside the scope of review.

How we review. We use your submitted materials, test your App in the environment where it runs, test live endpoints where they apply, and ask for written attestation of controls we can’t observe. We judge a code finding by what the code does in your App, not by the pattern alone.

What review is not. Review is not a testing service, a security audit, or a complete list of defects. If we hit a blocking issue, such as a failed installation or OAuth flow, we stop the review there and send you that feedback. We review Apps only through the submission form. We don’t pre-review Apps, give advance approval, or check fixes outside the queue.

Issues outside this list. If we find a concrete risk to users or their sites during review — such as exposed credentials, unauthorized data access, insecure handling of payment data, or malicious code — we may require a fix before approval, even in code outside the scope above. These guidelines also don’t list every issue that can block approval. If review finds a legitimate concern about security, privacy, reliability, user safety, platform integrity, or Marketplace quality, we may require changes or reject the App.

What approval means. Approval covers the version, configuration, permissions, and behavior we reviewed. Material changes or new evidence can require another review. Approval does not certify your App’s overall security.

Safety / Legal

Ensuring the safety and security of our users and their projects is our utmost priority when it comes to Webflow Apps.

Malicious, Damaging, or Objectionable Content

1. We do not allow Apps that intend to harm or compromise the security of our users or their projects.
2. Content that is offensive, insensitive, or intended to disgust is strictly prohibited.
3. Ensure that your App fully adheres to our Acceptable Use policy.

Intellectual Property

1. Ensure that your App only uses content for which you have the necessary rights, licenses, or permissions.
2. Do not infringe upon the intellectual property rights of others, including trademarks, copyrights, or patents.

Compliance

1. Comply with all applicable laws, regulations, and legal requirements in the jurisdictions where your Marketplace App is available.
2. Do not engage in any illegal activities or promote content that is prohibited or restricted by law.
3. You may want to consult legal counsel if you have additional questions.

Privacy and Data Protection

1. It is imperative that your App respects user privacy and handles personal data in accordance with relevant privacy laws and regulations. Apps that infringe on individuals’ privacy rights or misuse their data in any way will be removed from the marketplace.
2. Provide clear and transparent information to users about the collection, storage, and use of their data within your Marketplace App.
3. Implement appropriate security measures to protect user data from unauthorized access or breaches.

Authentication / Permissions

Webflow requires OAuth 2.0 for authenticating Apps. Do not collect Webflow credentials manually or implement workarounds that bypass the OAuth authorization flow.

Scopes and least privilege

1. Apply the Principle of Least Privilege when requesting OAuth scopes. Every scope you request must be required for your App’s declared functionality and invoked by a documented API endpoint your App calls.
2. The OAuth scopes your App requests must match the functionality described in your listing. Reviewers will verify that requested scopes correspond to the functionality you advertise.
3. If your App only displays Webflow data, request :read scopes only. If your App only pushes data to Webflow, request :write scopes only. Do not request both directions for a resource unless both are genuinely used.
4. Do not request workspace-level scopes when site-level access is sufficient for your App’s declared functionality.
5. Use authorized_user:read or the Get User Info endpoint to confirm user identity. Do not request broader scopes such as sites:read or workspace:read solely for identity confirmation.
6. custom_code:read and custom_code:write allow your App to inject site-wide JavaScript and are treated as elevated-risk scopes. Request them only when custom code injection is a disclosed, declared feature of your App — see the App-delivered code and injected scripts guidelines below.

App configuration

1. Your OAuth Client ID configuration must match your declared App type and architecture.
2. The API type enabled in your Webflow Developer Workspace must align with your declared App type, permissions model, and intended functionality.
3. The scopes requested in your install or OAuth URL must be equal to or a subset of the scopes configured in your App’s settings. See installation configuration for details.

OAuth flow security

1. Include a unique state parameter on every OAuth authorization request and verify the returned value before exchanging the authorization code. This protects users from cross-site request forgery attacks.
2. The redirect URI used in your OAuth flow must exactly match the redirect URI registered in your App’s settings.
3. Authorization codes are valid for 15 minutes and may only be used once. Exchange them for an access token immediately. Do not retry, persist, or log authorization codes.

Token security

1. Store OAuth tokens in secure, server-side storage — an encrypted database or secrets manager. Tokens must never be stored in browser local storage or session storage, kept in plaintext server-side storage, exposed in client-side code, written to logs, or included in responses.
2. Your client_secret is a private credential. Never include it in client-side code, public repositories, build artifacts, image layers, pipeline logs, or any other location accessible outside your secure server environment.
3. Implement token refresh and expiry handling correctly. Refresh tokens must never appear in logs, expired tokens must not be used, and expiry errors must be handled — not silently ignored.
4. Users must be able to fully revoke your App’s access to their data. When a token is revoked, your App must stop making API calls with it and delete it from storage.
5. API tokens, keys, passwords, and login credentials for the Webflow API are tied to you as the developer. Do not share them with third parties under any circumstances, in line with our Developer Terms of Service.

Session behavior

1. Complete the OAuth flow once at install or upon explicit re-authorization. Do not re-trigger the Webflow OAuth flow on login, session expiration, page refresh, or other routine events — users should be able to log back in to your App with standard authentication without redoing OAuth.
2. Manage OAuth tokens so user sessions persist across logins. Signing out of your App must not invalidate the underlying Webflow authorization unless that is the explicit intent.

Performance / Technical

All Webflow Apps must adhere to the following guidelines:

Performance

1. Optimize your App for efficient resource usage to provide a smooth and responsive experience to users.
2. Avoid long-running background processes or tasks that may impact the overall performance of your App.
3. Regularly monitor and address any performance issues or bottlenecks to maintain a high-quality user experience.
4. Apps that have persistent performance issues may be subject to removal from the Marketplace.

Technical

1. Apps should only utilize official Webflow APIs — the Data API and the Designer API — and should not require users to install separate packages that manipulate Webflow.
2. Ensure that your App’s source code is well-organized and adheres to industry standards and conventions. It should be easily readable, maintainable, and free from unnecessary complexity. For working examples of the patterns we expect, see the official starter and example apps in the Webflow-Examples GitHub organization.
3. Deliver any code that runs on customer sites through official mechanisms such as the Custom Code API. We recommend against asking users to copy and paste scripts into their site manually: manually pasted code sits outside your App’s lifecycle — your App can’t version, update, or remove it — and it can run twice when your App also applies the same script through the API.

App-delivered code and injected scripts

Code your App delivers to customer sites — such as scripts registered and applied through the Custom Code API — runs under your responsibility, as part of the service relationship between you and your customer. In line with the review scope, review verifies how that code is registered, disclosed, and removed through Webflow’s APIs.

1. Deliver code to customer sites through the Custom Code API, so users can see, manage, and remove what your App applies.
2. Disclose what your App delivers. Your Marketplace listing must clearly state what code your App applies to customer sites, what it does, where it runs, and why — vague or buried disclosures are not permitted. Remotely loaded or externally controlled resources that affect App behavior must be disclosed at submission. Apps whose declared purpose is transforming page content (for example, translation or accessibility tools) must disclose that behavior at submission and in their listing. Third-party tag managers, ad networks, and affiliate tracking scripts may only be delivered if your App’s declared purpose explicitly covers this functionality.
3. Uninstall must clean up. When a user uninstalls your App, remove the Custom Code your App registered and applied through the API — at both the site and page level — while preserving unrelated customer scripts, and delete Webflow-side data your App applied. If an applied resource cannot be removed automatically, provide clear removal instructions.

Recommended practices for published-site code

The following are strongly recommended for code your App runs on customer published sites. They are not review gates — they are what separates a dependable integration from a support burden, and your customers will hold you to them:

• Reference injected scripts at immutable, versioned HTTPS URLs with a subresource integrity (integrity) attribute and crossorigin="anonymous", so the code serving your customers’ visitors is verifiably the code you shipped. Avoid loaders that fetch and execute undisclosed remote code at runtime.
• Keep inline <script> blocks to static configuration; keep functional logic in hosted files.
• Scope script injection to the pages that need it.
• Prefer adding self-contained functionality over modifying, restyling, or removing existing page content. When a change belongs in the user’s site design, make it through the Designer APIs so the user can see and own it.
• Validate message event origins and navigation destinations, avoid overriding native browser functions or prototypes, and make initialization idempotent so double-loading is safe.
• Handle payment and checkout surfaces with particular care: avoid reading, writing, or listening on payment form elements from injected code, and never collect visitor-entered data beyond what your listing discloses.

Credential and authentication fields

1. Apps must not read, collect, modify, transmit, or act on password fields, login fields, authentication fields, or other fields used to enter authentication credentials in a user’s Webflow site.
2. Apps that inspect forms, DOM content, or user input must exclude those fields from collection and rule actions.

Additionally, Apps built using Designer APIs must adhere to the following additional guidelines:

Technical (Designer Extensions)

1. Strive for clarity and consistency in your codebase, utilizing meaningful variable and function names, proper indentation, and appropriate comments where necessary.
2. Do not use statements or patterns that could introduce vulnerabilities in your App — for example, eval() statements, excessive use of global variables, or inserting untrusted data into your UI as raw HTML. Rendering and managing your extension’s own UI inside its frame is expected; reading or modifying the user’s site or the Designer itself must happen exclusively through the official Designer APIs, never by manipulating the Designer’s interface directly.
3. Use only DOM manipulation techniques supported by the Webflow Designer. Unsupported techniques put Designer stability and forward compatibility at risk.
4. Externally hosted iframes may be used for authentication flows. Apps should not use an externally hosted iframe as the primary App UI or runtime surface when that surface can change independently of the reviewed App submission.
5. Do not use dynamic code execution patterns such as new Function(), setTimeout(string), or setInterval(string) — these introduce code injection risk. Use static, explicitly defined functions instead.
6. Do not insert <script> tags at runtime through innerHTML, document.write(), insertAdjacentHTML(), or similar methods. Runtime script injection bypasses static review and introduces supply chain risk. Use static imports or bundled modules.
7. Do not override, proxy, or reassign native browser functions, Webflow globals, or native prototypes. Overrides affect other code running in the Designer and can evade review.
8. Ensure your App code is compatible with Webflow’s enforced Content Security Policy. Inline event handler attributes, javascript: URIs, and unsafe-eval patterns will not pass review.
9. Standard minification is fine, but do not obfuscate your code beyond it. Obfuscation — such as encoded string arrays, runtime atob()/btoa() decoding, or scrambled self-invoking functions — conceals App behavior from review and is not permitted.

Network / External services

Transport security

1. Every endpoint your App contacts or serves — outbound requests, OAuth redirect URIs, webhook receivers, embedded URLs, and backend APIs — must use HTTPS.
2. Every URL embedded in your App must point to a production environment. Staging, development, localhost, loopback, private network, and cloud metadata references must be removed before submission.

Credentials and secrets

1. Never embed API keys, tokens, passwords, or other secrets as string literals in your App. Use environment variables and a secrets manager instead.
2. Credential-bearing headers — Authorization, Cookie, or equivalent — must never be forwarded to non-Webflow domains. Webflow credentials must stay within Webflow.

Request handling

1. External redirects must be strictly necessary for OAuth or login, lead only to trusted domains you declare, and never expose sensitive data in URL query strings.
2. Every message event handler in your App’s Designer Extension or App UI surfaces must validate event.origin against an explicit allowlist before processing the payload. For published-site code, origin validation is a recommended practice — see App-delivered code and injected scripts.
3. When using user-supplied URLs to make server-side requests, validate them against an explicit allowlist before making the request. A blocklist alone is not sufficient.
4. Configure Cross-Origin Resource Sharing (CORS) to allow requests only from origins you control. Wildcard (*) or untrusted origins are not permitted.

Backend authentication

1. Protect Webflow-authenticated endpoints from untrusted origins. A backend endpoint that carries Webflow authority — one that holds or uses your App’s Webflow OAuth token, or acts on the authenticated user’s Webflow site or data — must ensure an untrusted origin cannot read or mutate a Webflow-authenticated response or state. Satisfy this however your architecture requires: bearer credentials a cross-origin page cannot obtain or automatically send, or an explicit origin allowlist where sessions are ambient. Review verifies this by probing live endpoints — refusing a hostile origin and rejecting a forged identifier with no valid session — not by inspecting backend source.
2. Backend endpoints must verify the identity of incoming requests using an authenticated session or signed token. Never trust client-supplied identifying parameters such as siteId without verification — they can be manipulated.
3. Treat endpoints called by published-site code as untrusted. Do not rely on public Webflow IDs, DOM values, Origin, or Referer headers as authentication, and ensure unauthenticated runtime requests cannot mutate customer configuration or persisted App state.

Data access / Data integrity

Data access

1. Access Webflow data exclusively through official Webflow APIs (see the Technical guidelines above).
2. Do not bulk copy, scrape, or otherwise bulk export Webflow Content for use on non-Webflow services unless provided for in a separate written agreement with Webflow, per our Developer Terms of Service.
3. Respect Webflow API rate limits. Implement exponential backoff and a maximum retry limit when receiving rate-limit responses.
4. Sanitize API response data — particularly user-generated CMS content — before rendering, storing, or forwarding it. Unsanitized data introduces XSS and injection risk.
5. Gate every write and delete operation behind authenticated, verified triggers, and apply schema validation to every input reaching server-side logic. Never interpolate raw input directly into a query, command, or file path.

Webflow as the source of truth

1. Webflow must remain the authoritative source for site data. Do not maintain versions of Webflow data that conflict with or operate independently of the current Webflow state.
2. Persist every data modification made through your App back to Webflow using official APIs. Do not store editable copies of Webflow data that can diverge from the Webflow state.
3. When displaying Webflow data, indicate when it was last fetched and provide a refresh mechanism so users never act on stale data unknowingly.
4. Keep derived or supplemental data — analytics, AI suggestions, drafts — visually and contextually distinct from live Webflow data, and never silently overwrite Webflow data with derived values.
5. When your App presents external data alongside Webflow data, clearly distinguish between the two so users always know which data came from their site and which came from outside.

Data Client Apps

Data Client Apps operate server-side, hold OAuth tokens, and access the Webflow Data API through their own backend infrastructure. In addition to all guidelines above:

1. Your OAuth Redirect URI must be a single, fully-qualified HTTPS URL on a production domain. Wildcards, localhost, HTTP, IP addresses, tunneling services (such as ngrok or localtunnel), and ports other than 443 are not permitted.
2. Every domain serving your App — Install URL, Redirect URI, webhook receivers, backend APIs — must have a valid, current TLS certificate issued by a trusted certificate authority.
3. Every URL you submit must resolve correctly via DNS and respond over HTTPS at the time of review.
4. Scan server-side components for known CVEs and unmaintained dependencies before submission. Backends with known-vulnerable or deprecated dependencies put user data at risk.
5. Maintain reasonable backend uptime and availability. Backends that are frequently unreachable — including during review — cannot deliver the functionality advertised in your listing.
6. Provide three written attestations at submission, kept on file by the review team: your App’s Webflow OAuth token is encrypted at rest, stored server-side only, and deleted on uninstall or revocation. Review accepts these as attestations and verifies the Webflow-authenticated endpoint requirement by probing live endpoints — it does not audit your backend source.

Localization

If your App reads or writes content on sites that use Webflow Localization:

1. Handle localeId and cmsLocaleId parameters correctly. Never overwrite localized content with primary-locale values without user awareness.
2. Preserve data-w-id attributes and other Webflow-required identifiers when updating HTML content. These identifiers carry custom styling, animations, and links across locales.
3. Specify the intended localeId on every write operation against locale-aware endpoints. Omitting it propagates changes to the wrong locale.

Design / Usability

Webflow users gravitate towards products that are easy to use, polished, and designed with intentionality. The guidelines below represent the minimum expectations for a Webflow App, however, we strongly encourage you to design your App in a way that users find useful.

All Marketplace Apps must adhere to the following guidelines:

Consistency

1. Ensure that your App’s design and user interface are consistent throughout, providing a cohesive and familiar experience.

Usability

1. Provide comprehensive and user-friendly documentation or help resources to assist users in understanding and utilizing your App effectively. We recommend utilizing a Webflow site as your platform for hosting support docs.
2. Ensure that end users are provided with a fully functional experience that is free of placeholder content and test data.

Listing language

1. All Marketplace listing content — App name, short and long descriptions, and feature list — must be written in English. Marketplace surfaces are English-first, and listings are reviewed in English.
2. If your App’s user interface or user-facing experience operates in a language other than English, your listing description must clearly state which language(s) your App operates in, so users know what to expect before installing.

Accessibility

1. Design your App with accessibility in mind, ensuring that it can be used by individuals with disabilities or different abilities.
2. Follow best practices for accessibility, such as providing alternative text for images, supporting keyboard navigation, and maintaining sufficient color contrast.

User Feedback and Testing

1. Gather user feedback and conduct usability testing to identify areas for improvement and refine your App’s design.
2. Incorporate user suggestions and address reported usability issues in a timely manner to enhance the overall user experience.
3. Apps that are error prone, not actively maintained, or those that present users with persistent usability issues will be removed from the marketplace.

User interaction

1. Popups, pop-unders, and unsolicited windows must be triggered only by direct user interaction — never on load or on a timer.
2. Calls to WebRTC, getUserMedia, and getDisplayMedia must be triggered by direct user interaction and preceded by a clear disclosure UI. Silent activation of camera, microphone, or screen capture is not permitted.
3. Every state-changing action must be traceable to a direct user interaction event, not fired on load or on a timer.

Additionally, Apps built using Designer APIs must adhere to the following additional guidelines:

Consistency (Designer Extensions)

1. Align the visual style, typography, and color palette of your App with our App design guidelines to create a seamless integration.
2. Maintain consistency with established Designer patterns and affordances. For example:
   • Use component icons only to represent components
   • Follow existing interaction patterns that users are familiar with
   • Avoid creating new UI patterns that could confuse users or conflict with Designer functionality

Usability (Designer Extensions)

1. Design your App with a user-centric approach, considering intuitive navigation, clear labeling, and logical flow.
2. Ensure that your App’s interface is visually appealing, consistent, and accessible to a wide range of users.
3. Minimize user input requirements and strive for simplicity in App interactions.
4. Avoid implementing intrusive or disruptive features that may negatively impact the usability or overall user experience.
5. Do not use keyboard shortcuts to invoke your app or any functionality within it.

Business / Branding

Monetization

1. Provide clear and transparent information regarding any fees, subscriptions, or in-App purchases associated with your Webflow App.
2. Avoid deceptive or misleading practices related to monetization, such as hidden charges or misleading pricing information.

Advertising

1. Do not display ads to users to help maintain a focused and distraction-free experience.

Branding

1. Avoid unauthorized use of trademarks, logos, or copyrighted materials belonging to others.
2. Clearly indicate any affiliations, partnerships, or endorsements in a truthful and transparent manner.
3. Impersonating a company as an App author will result in rejection. Please provide accurate, reliable contact information for user inquiries, support issues, or feedback.

One Developer Account Policy

1. Developers listing apps in the Webflow App Marketplace are limited to using only one developer account for active marketplace listings. Submitting and/or listing apps using multiple developer accounts is strictly prohibited.
2. Any developer found violating the one-account-per-developer policy, including attempts to circumvent app listing restrictions or marketplace rules, may face immediate enforcement actions. We encourage all developers to uphold integrity and transparency within our developer community.

Audit / Cooperation

Webflow may audit records or activity related to your App’s access to the Webflow API and the Marketplace to verify compliance, as set out in our Developer Terms of Service. Cooperate with these compliance audits, including providing requested records, logs, agreements, and written reports of your App’s current deployment and API usage.

Submitting your App

Submission Prep

Submit your App only when it is complete, works end to end, and is ready for users. Don’t submit beta, incomplete, or pre-release Apps. The App you submit must be the App users get after approval.

Before you submit:

1. Test. Test. Test! Test every core workflow end to end. Fix errors that stop or disrupt normal use, and remove placeholder content and unfinished features.
2. Check installation and OAuth. Confirm that your installation URL works, that a user can approve the OAuth request, and that your App handles a denied request. The scopes your App requests must match its App configuration.
3. Check disconnect and uninstall. Confirm that users can disconnect and reconnect Webflow, and that uninstalling removes what your App added.
4. Give us full access. If your App has accounts, paid tiers, or gated features, give reviewers access to everything you submit: a review account, a full-featured demo mode, or the credentials and sample data we need. If your App depends on a third-party service, include working access to that service too.
5. Keep the review account active. The account must include your highest plan or tier, must not expire during review, and must stay active after approval so we can run follow-up reviews and audits.
6. Keep backend services live. Keep every backend service, API, and production endpoint your App uses running and reachable during review.
7. Explain non-obvious features and in-App purchases. Cover them in your review notes and demo video, and include supporting documentation if needed.

If review can’t get past installation, OAuth, or another blocking issue, we stop there and send you the feedback. Fix the issue and retest the whole App before you submit again.

How to submit

All prospective Apps must be submitted through our Webflow App submission form. To expedite the approval process, please provide all requested details about your App.

Before submitting, you’ll need to prepare the following items (see the App listing guide for full asset specifications, and Submitting your App for the step-by-step walkthrough):

1. App Logo: A logomark (not a text-based logotype), 900x900px with a 1:1 aspect ratio. Browse the Marketplace for examples.
2. App Detailed Description: Avoid vagueness. Clearly explain your app’s function and its benefits to users. Listings must be written in English; if your App’s user experience operates in another language, your description must state which one (see Listing language).
3. App Screenshots: Provide 3-5 images (1280x846, PNG or JPG, 2MB max each) that highlight the App features with clear visuals.
4. Demo Video: Every submission must include a private demo video (2-5 minutes) that walks the review team through your App’s installation, setup, and core functionality, in English or with English subtitles. If your App uses a Data Client, the video must also demonstrate a working OAuth flow for users approving and denying the request, and describe in detail your deep integration with Webflow. You may provide a private link to Loom, YouTube, or Google Drive.
5. Upload your bundle and review files (Designer Extension and Hybrid Apps): Upload your production bundle through the App version manager in your Workspace’s App settings (Apps & Integrations → Publish extension version), without source maps. When that bundle is new or changed, also upload a private ZIP containing the source maps, package manifest, and lockfile from the same build in the submission form’s Source map artifact field (or, for apps that ship their source unchanged, the source files and a short README on how the bundle is packaged). Source maps stay private to the review team and are never published. A production bundle that includes source maps is not accepted. Review begins once both the form submission and the bundle upload are received.
6. Checks the form runs when you submit: The submission form validates a published testing site on a .webflow.io staging domain with your App installed; for new or changed Designer Extension bundles, the private source-map ZIP; your listing copy, URLs, and install URL against these guidelines; and your App Review Preflight receipt, required for new Apps and for updates that change code or scopes. A receipt that reports changes_required blocks submission until you fix every Blocker and Required update and run Preflight again. See Submission artifacts and What the form checks when you submit.

After submitting

We’ll email you to confirm we received your submission, and we aim to send a decision within 10 business days. All review email goes to the address on your Webflow account.

Review decisions. Each review ends with one of three decisions:

• Changes requested: We list the issues that block approval. Fix every item, retest your App, and resubmit.
• Approved: We email you when your App is approved and published.
• Rejected: Your App doesn’t meet the Marketplace requirements. You can address the feedback and resubmit when your App is ready. We don’t test or support your App between submissions.

Feedback covers the issues that blocked approval in that review. It isn’t a complete list of defects, so test the whole App before you resubmit, and fix all earlier feedback, not only the latest round.

Repeated submissions. Every review round takes reviewer time from other developers in the queue. If an App keeps coming back without fixes to earlier feedback, or with blocking issues that testing would have caught, we may pause new submissions for that App for a period of time. Repeated pauses get longer and can end in rejection. For an App already on the Marketplace, we may also limit its availability until the issues are fixed.

Review integrity. Don’t hide functionality from reviewers, show reviewers a different experience than users get, remove required behavior after approval, or submit misleading materials or credentials. Any attempts to exploit the Marketplace App APIs or review process, such as providing false information, engaging in plagiarism, deceitful manipulation of user files, or data theft, will result in immediate removal. Additionally, you will be banned from publishing future Apps in our community.

Webflow may take appropriate action for Apps that violate the Marketplace Guidelines, Developer Terms, or review requirements, including limiting App availability or API access after approval where permitted by applicable terms.

We look forward to reviewing what you’ve developed! For more context, please reference our Developer Terms of Service.