App review guide
How to prepare a Webflow app for review without losing the operating boundary
Prepare a Webflow app for review by proving the exact installation and user path, explaining every permission and external service, testing empty, denied, disconnected, and failure states, and binding screenshots and documentation to the submitted version. Review readiness is a product and operating claim, not a checklist of marketing assets.
- 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.
Signals this guide applies
- 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.
A bounded way to proceed
- 01
Freeze the review candidate
Record the submitted version, deployment identity, Webflow configuration, external endpoints, privacy policy, support route, and test account instructions. Ensure every screenshot and statement refers to that same candidate.
- 02
Explain access and data
Map OAuth scopes, site permissions, data categories, storage locations, subprocessors, retention, deletion, and disconnect behavior. Use plain language that matches both implementation and consent screens.
- 03
Rehearse the reviewer journey
Install from the permitted review path and test onboarding, primary job, empty state, denied consent, expired session, disconnected provider, invalid input, retry, and uninstall. Capture evidence from the reviewer-visible surface.
- 04
Package support and release proof
Provide concise setup steps, known limits, troubleshooting, support ownership, monitoring, and rollback. Keep production publication separate from review approval and verify the listed version again after any requested change.
Artifacts an operator can inspect
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.
Questions operators ask
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.