App review guide
How to prepare a Webflow app for review
Choose the exact app version to submit and test the installation and main user task. Explain its permissions and external services. Test empty, denied, disconnected, and failure states. Make sure screenshots, documentation, and support instructions describe that same version.
- Good fit
- Use this approach for Marketplace apps, Designer extensions, data clients, or integrations whose review depends on permissions, user experience, support, privacy, and repeatable installation behavior.
- Pause when
- A polished demo is not a substitute for an installable submitted build, and a locally successful API call does not prove the reviewer can authorize, configure, and use the app in the review environment.
When this approach helps
- The app crosses Webflow, an external provider, and a hosted runtime with separate identities.
- Permissions or data handling are hard to infer from the visible product path.
- A reviewer must reproduce setup and failure behavior without developer assistance.
Follow these steps
- 01
Identify the submitted version
Record the app version, deployment, Webflow configuration, external services, privacy policy, support contact, and test account instructions. Match screenshots and claims to that version.
- 02
Explain access and data use
List OAuth permissions, site access, data categories, storage, subprocessors, retention, deletion, and disconnect behavior. Use plain language that matches the app and consent screens.
- 03
Try the reviewer’s path
Test installation, setup, the main task, empty states, denied consent, expired sessions, disconnected providers, invalid inputs, retry, and uninstall. Capture what the reviewer can see.
- 04
Include support and release records
Provide the support and recovery instructions for the submitted version. Keep the release record and known limits alongside the review evidence.
Documents and records to keep
Review candidate manifest
The manifest binds source revision, deployment, app configuration, requested permissions, external services, documentation, screenshots, and submission identifiers.
Reviewer journey evidence
A reproducible sequence shows installation, consent, primary task, key failure states, disconnect, and uninstall from the same build the reviewer receives.
Release and support runbook
The runbook names monitoring, incident response, customer support, version changes, rollback, credential rotation, and the person responsible after approval.
Common questions
What evidence should accompany a Webflow app submission?
Provide version-bound installation steps, permission explanations, privacy and support links, reviewer credentials if allowed, primary and failure-path evidence, external-service details, and a way to identify the exact deployed candidate.
How should OAuth be tested before Webflow app review?
Test first consent, repeat consent, denial, expired sessions, wrong account or site, provider disconnect, revoked grants, and app uninstall. Confirm user-facing scope language and verify that revoked access actually stops protected operations.
Does Marketplace approval prove the live app works for every customer?
No. Approval establishes a review decision for a submitted candidate. The owner must still verify publication, installation, runtime health, support readiness, provider changes, and customer-specific permissions after release.