/wix-app

Wix App Market Review

Use this reference when preparing a Wix CLI app for App Market submission, auditing review feedback, or checking whether an implementation is likely to pass technical review. Keep the review evidence-based: classify what the app actually does, then mark each relevant requirement as Confirmed, Not applicable, or Needs confirmation.

This page covers code-facing and repository-verifiable requirements. App Dashboard, pricing-page setup, company profile, and listing-copy checks require separate dashboard or listing verification unless the user provides direct evidence.

Review Workflow

1. Identify the app surfaces first: billing model, auth/password usage, cookie usage, extension types, live-site surfaces, dashboard/setup surfaces, Wix business-solution dependencies, and webhooks.
2. Start with a report-only pass. List confirmed gaps, why they matter, and official Wix documentation links where available.
3. Do not mark a requirement as missing unless code, config, user statements, runtime behavior, or explicit absence supports that finding. Otherwise mark it Needs confirmation.
4. Before flagging secrets, config leakage, or similar security issues, verify the exposure is in a tracked file, the current diff, build artifacts, or another review-relevant surface. Do not treat a local-only workspace file by itself as repository exposure.
5. Do not infer app billing configuration from Wix Business Solutions Pricing Plans SDK/API usage. Business-solution Pricing Plans are for a Wix user selling plans to customers; App Billing/App Plans are for charging site owners for the app.
6. For any code-facing gap the user asks you to fix, implement the fix through the relevant wix-app extension reference first, then run validation.

Expected Output

Group findings by priority:

• Technical blockers: confirmed issues that are likely decline reasons.
• Should-fix items: high review risk, but not enough evidence to call them definite decline reasons.
• Nice-to-have hardening: improvements that reduce risk without blocking submission.
• Needs confirmation: requirements that cannot be verified from available evidence.

For each finding include:

• Applicability
• Evidence
• Impact
• Recommended fix
• Verification
• Confidence

Preserve qualifiers from the taxonomy and docs. Do not upgrade recommended, if applicable, or surface-specific guidance into a universal requirement.

Technical Checklist

Work through this before submission. Only applicable unchecked items are potential decline reasons.

Billing and Payments

• All in-app purchases route through Wix Billing unless Wix explicitly approved the app as Partner Billed; approved Partner Billed apps report charges through External Billing Events.
• No external purchase buttons, links, QR codes, license keys, or other custom mechanisms unlock paid content.
• Full checkout flow tested for every plan.
• If the app has premium features, there is a clear in-product upgrade link or CTA.
• Credits do not expire.

Setup and Access

• App configuration URLs are public and do not use localhost.
• A usable setup/settings UI exists. Embedded Script apps need a dashboard page.

Instance and Identity

• instanceId is used for user/site identification, not cookies or sessions.
• Billing is separated per instanceId.
• Auto-login works when the user reopens the app from Manage Apps.
• Site duplication is handled through originInstanceId: treat the copied site as a new install linked to the original and copy applicable settings/content where possible.
• Required Wix apps, such as Stores or Bookings, are checked through Get App Instance and surfaced clearly if missing.
• If the app supports Wix Stores catalog data, both Catalog V1 and Catalog V3 are supported. See STORES_VERSIONING.md.

Webhooks

• Any implemented webhook returns HTTP 200 on successful receipt.
• App Installed and App Removed webhooks are considered for lifecycle provisioning and cleanup. They are recommended, not a universal hard requirement.

Permissions

• Only minimum required permissions are requested.
• Redundant or overlapping permissions are removed.

Security

• Signed instance verification happens server-side before trusting user/site context.
• Signed-instance-backed edit/save actions validate signDate; stale signatures require refresh before continuing.
• All endpoints are HTTPS with no HTTP fallback.
• In-product flows avoid alert() and confirm(); use Wix modal, inline status, toast, or another surface-appropriate feedback pattern.
• XSS protection covers all user input fields.
• Passwords are stored as salted hashes, such as bcrypt or SHA-256 with a unique salt per password.
• Password reset uses an expiring email link and never sends raw passwords.
• Sensitive data is not stored in cookies and is encrypted where needed.

UX and Display

• In-product flows use Wix popup/modal patterns where appropriate. OAuth and documented Wix pricing-page upgrade CTAs are exceptions.
• First install shows realistic demo data, not placeholder lorem ipsum.
• Ads are not shown to site visitors unless ad display is the app purpose and the app has the required permits.
• Review prompts, if present, are non-blocking and do not force or incentivize reviews.
• Plugin content relates to the host app's core functionality.

Performance and Quality

• Startup and load times meet App Market expectations.
• No known bugs or console errors remain.
• Supported-browser matrix is tested.
• Live-site extensions are responsive across screen sizes.
• Dashboard surfaces support the required desktop layout.

SEO, Accessibility, and Localization

• Widget components do not render <h1> tags.
• User-facing images expose alt-text customization where applicable.
• App output is UTF-8 encoded.
• Website components meet accessibility standards.

Cookie Consent

• Cookie consent workflow activates/deactivates cookies per visitor preferences.

Implementation Notes

Payment and Billing

All apps that collect money must route payments through Wix Billing unless Wix granted a formal exception. Approved Partner Billed apps still need to report charges/refunds through External Billing Events and submit revenue reports.

App Instance and Identity

The instanceId uniquely identifies an app installation on a site. Use it for identity, app data, and billing. Site duplication creates a new instanceId; use originInstanceId to relate the copied site to the original.

Webhooks, Setup, and Permissions

Security

UX, Performance, and Accessibility

Technical Review Taxonomy

Use these IDs for traceability when mapping findings to review feedback.