When you submit your app to the Wix App Market for review, Wix checks your app thoroughly against our guidelines. This article includes the basic checks and tests you're required to make during development and before you submit your app for review.
1. In the your app's dashboard click on the Test Your App button and choose Preview Listing.
2. Click on Test on Dev Site.
3. Select a development site.
4. Click on Test App - at this point Wix redirects the user to your app URL with a token.
5. A consent modal should appear – this is how users authorize the permissions you added in your app's dashboard. If not, check your OAuth flow setup.
6. Accept the permissions.
7. Wix will send the user to your redirect URL, and your app dashboard should show up and commence its onboarding flow.
8. At this point, the app is installed on the user's site and you should have their instanceId – this is the unique identifier for the user's site that the app is installed on.
9. Once the user completes the onboarding flow, call Send BI Event, specifying APP_SETUP_FINISHED for the eventName parameter.
Make sure that you only added the minimum necessary permissions for your app to function.
If you added scopes: remove all the permissions already included in that scope. For example, the Manage Orders scope already includes Read orders, Manage bookings and Read bookings, etc.
Use the Trigger Test button next to your webhook in your app's dashboard to make sure you receive it.
Trigger the webhooks using your Wix site. For example, create an order on the site and make sure that you receive the webhook response that an order has been created successfully.
The response in the webhook log should be 'Success' – if not check the URL and make sure to return a 200 response.
If your app has an internal dashboard component the consent window should close when you've approved the permissions and your app will open in the Wix dashboard.
Close the app.
Open the app from the Manage Apps section in your Wix site manager – the app's dashboard should open.
That the script itself has a dynamic parameter, the recommended syntax is: <script id="my-script" src="https://cdn.example.com/pixel.js?id={{KeyName123}}" async='true'></script>
Make sure you've gone through everything in our dedicated app pricing guide.
Apps that use Wix internal billing
Test the entire checkout flow of the app installed on a Wix site: test each plan, cancel plan, and more.
Redirect the user within the app to Wix Pricing Page: https://www.wix.com/apps/upgrade/APPIDHERE?appInstanceId=INSTANCEIDHERE
Don't allow users to downgrade through your pricing page. Downgrades or switches from yearly to monthly pricing require subscription cancellation and repurchase of the lower-priced plan. This is due to how Wix's billing system handles subscription modifications to ensure accurate billing and prevent revenue discrepancies.
Add all the plans to your app's dashboard and connect each to Wix checkout using the Billing API.
Test each plan, and make sure they all lead to the Wix checkout.
Make sure the prices are consistent with the ones you added in the app dashboard.
Partner Billed Apps
If you have dynamic plans or your business model is based on fees, please choose Dynamic Pricing and add plans.
Make sure all your plans are added to your app's dashboard.
Install the app on multiple Wix sites and use instanceId to make sure that you show the relevant account details for each site (separated billings, dashboard, etc.).
Install the app on your Wix site via your app's dashboard.
Go through the onboarding flow and create an account if needed, upgrade the app and use it.
Install the app on a second Wix site.
At this point, you should identify that it's a new user using instanceId – you shouldn't identify users by their session/cookies.
If the account is needed for your app, then:
Case 1: If you support multiple site connections under one account, build a flow that allows users to switch between their accounts. The user should be able to log in to your app with their existing account, but the details should be connected to the site they opened the app with and your app should distinguish between the sites that the user installed the app on by the instanceId.
Case 2: If you support one account per site, you should support a flow where you let the user know that they already have one site connected under their account and if they want they can disconnect it or create a new account.
For both cases, billing should be separate for each site.
After a user creates an account for your site and opens the app through Manage Apps, they should be auto logged in based on the instanceId we send you when the user clicks Open App.
If your app requires Wix Stores, Wix Bookings etc., then use the Get App Instance API (installedWixApps field) to make sure that the user has Wix Stores installed on their site.
If they don't, then please create a flow that lets the user know they need Wix Stores to use your app (a message saying so, etc.).
A duplication is effectively a new install of your app, but users skip the consent flow. This might mean that users access the app from a new instanceId without a refresh token.
Duplicate your test site with your app installed on it.
When your app endpoint is called, check if the instance parameter has an originInstanceId property. If it does, this means that the app is being copied from another site.
Once you've gone through everything in this list, you can submit your app for review and a member of our team will let you know if anything needs fixing before we publish your app.