Get to know our frameworks

Select an app template built on your preferred framework.

Build apps on our native app editor. Use drag and drop elements, Velo code and Wix APIs to develop custom features.

Streamline your app development process with the Wix CLI. Get a familiar developer experience with minimal setup and configuration.

Take full control over your app's tech stack, deployment, and hosting.

App templates

Wix Blocks templates

Wix CLI templates

Self-hosted templates

Kickstart your app development with templates built on your preferred Wix developer tool. Browse templates for practical foundation and get to know the Wix ecosystem.

Wix App Templates for Developers

This example apps can be used as a starting point for building your own app, for concrete examples of how to use Wix framework, or for inspiration.

Choose a template.<0 />Build an app.

Browse by:

How to build it step by step:

This template is built with:

Read how this template was built, step by step.

How we built this template

Deployment instructions:

Choose a package manager and run the command in your terminal.

Copy command

Before you get started, make sure you have the following:

Prerequisite steps

Get started with Wix CLI

Begin by setting up your Next.js project with your preferred hosting platform.

Select your hosting service

Start the deployment flow and set up your template repo on Netlify. After you finish set up, come back here and add your Netlify custom domain.

Copy the code from our Git repo to deploy your app on any platform that supports Next.js.

Start the deployment flow and set up your template repo on Vercel. After you finish set up, come back here and add your Vercel generated URL.

Add the base URL and give your app a name.

App details

Go to the app dashboard and test your app to ensure a smooth integration within the Wix ecosystem. <0>Learn more about app checks and testing</0>

Define your environment

Terminal

Related templates

Note

Warning

Your app name will be used as the namespace suffix.

Name your app to generate a namespace. This lets you refer to your app in code later on.

Go Headless

Build Apps

Client

API Preview

Ricos

Develop Websites

REST

Velo

GraphQL (Alpha)

# About the Catalog Versioning API

The Catalog Versioning API allows you to determine what version of the Wix-Stores Catalog a site is using. 
The two versions of the catalog ARE NOT backwards compatible. Supporting both versions of the catalog is critical, as sites will be spread across both versions.

## Motivation
In order to support our customer's needs and to support the best practices in a modern ecommerce platform, WixStores
has developed a new API. Designated **Catalog V3**, this new API will allow a more fine-grained control of your store,
as well as much better performance. This new API will make adding new features much easier, not only for Wix developers, but also for TPAs and Velo developers.

Unfortunately, not every store will be able to take advantage of this new API right away. Because of this, in order to use the Catalog API, services will need to first check which version of the Catalog is being used on a specific site.
In order to determine which API to use, it is important to call the `GetCatalogVersion` endpoint at the beginning of each flow.

### Catalog Domain Events
V1 Domain events will be sent for all updates to the catalog, even for sites using the V3 catalog. Each domain event has a new `CatalogVersion` field. 
This field can take the values `V1_CATALOG` or `V3_CATALOG`. This data can be used instead of calling the Versioning API.

## Before you begin
It’s important to note the following points before starting to code:
* The site owner must have the Wix Stores app installed.
* Your app must have the SCOPE.STORES/CATALOG_READ permission

## Sample Flows
* [Create a Product while supporting both V1 and V3 catalogs](slug::sample-flow#create-a-product-while-supporting-both-v1-and-v3-catalogs*fallback::./sample-flow.md#create-a-product-while-supporting-both-v1-and-v3-catalogs)
* [Handling domain events and webhooks](slug::sample-flow#handling-domain-events-and-webhooks*fallback::./sample-flow.md#handling-domain-events-and-webhooks)

## Terminology
1. **Catalog V1**: Original API for Wix-Stores. 
Eventually all sites will move off this version, but some stores will stay in this version for a while yet. Read more [here](fallback::../catalog/introduction)
2. **Catalog V3**: New API for Wix-Stores. Once original API is deprecated, this will be the new standard for Wix-Stores. Read more [here](fallback::../catalog-v3/products-v3/introduction)

---
## Notes
- The `GetCatalogVersion` endpoint takes no parameters. All necessary information is contained within your `AUTH` header.
- Once a store has been upgraded to `CATALOG_V3`, it will not be downgraded to `CATALOG_V1`
- Changing catalog versions is a once-in-a-lifetime event for a given store (site). One call to this endpoint will suffice for most catalog flows.

# Catalog Versioning API Sample Use Cases and Flows


## Create a Product while supporting both V1 and V3 catalogs
* Call [GetCatalogVersion](fallback::./get-catalog-version) to retrieve the catalog version.
* if the `catalogVersion` is `CATALOG_V1`:
    * Call [CreateProduct on the V1](fallback::../catalog/create-product) catalog
* if the `catalogVersion` is `CATALOG_V3`:
    * call [CreateProduct on the V3](fallback::../catalog-v3/products-v3/create-product) catalog

## Handling domain events and webhooks
On every change in catalog V1 and in catalog V3 we send relevant events.
To ensure smooth client migration from V1 to V3 until client started listening to V3 domain events, on every change in V3 catalog we also send duplicating V1 webhook.
But once client started migration to V3 catalog and listening to V3 event in addition to V1 event it would cause double event handling issue. To avoid this, we added a new field `originatedFromVersion` to all V1 webhooks. The client should check this field and ignore the V1 webhook if the `originatedFromVersion` is `CATALOG_V3`.


Let's consider example where you need to listen to Product Created event and save new product on your DB.
1. When you receive V3 [Product Created](fallback::https://dev.wix.com/docs/rest/business-solutions/stores/catalog-v3/products-v3/product-created) domain event, you have entire product entity in `createdEvent.entityAsJson`. Just save it in your DB or do whatever logic you need.
2. When you receive V1 [Product Created](fallback::https://dev.wix.com/docs/rest/business-solutions/stores/catalog/product-created) event, it might be originated from V3 catalog which you already handled in step 1, so you need to check `originatedFromVersion` field.
   * If `originatedFromVersion` is `CATALOG_V3` you can ignore this event.
   * Otherwise, you might want to do follow up call to [Get Product](fallback::https://dev.wix.com/docs/rest/business-solutions/stores/catalog/get-product) V1 API if event you receive doesn't have all data you need. Now you can save product in your DB or do whatever logic you need.


identityType

IdentificationData

WebhookIdentityType

ID of a site visitor that has not logged in to the site.

anonymousVisitorId

appId

ID of a site visitor that has logged in to the site.

memberId

ID of a Wix user (site owner, contributor, etc.).

wixUserId

data

eventType

The identification type and identity data.

instanceId

MessageEnvelope

An application definition id (app_id in dev-center). For legacy reasons may be UUID or a string (from Java Enum).

appDefId

An instance id. For legacy reasons may be UUID or a string.

state

Asset

State

dateDeleted

deleteOrigin

deleteStatus

initiatorId

DeleteContext

DeleteStatus

Namespace

A list of "assets" (applications). The same as MetaSiteContext.

assets

metaSiteId

timestamp

A meta site version. Monotonically increasing.

version

MetaSiteSpecialEvent

Emitted when meta site was permanently deleted.

Emitted when an application is provisioned (installed).

Emitted when an application is removed (uninstalled).

Emitted when meta site is marked as template.

Emitted when meta site is marked as a WixSite.

Emitted on the first* publish of the meta site (* switching from unpublished to published state).

Emitted when meta site name (URL slug) is changed.

Emitted on a meta site transfer completion.

payload

newNamespace

oldNamespace

NamespaceChanged

Not only UUID. Something here could be something weird.

An instance id from which this instance is originated.

originInstanceId

ServiceProvisioned

ServiceRemoved

A context in which meta site was created.

context

namespace

A meta site id from which this site was created.

In case of a creation from a template it's a template id.
In case of a site duplication ("Save As" in dashboard or duplicate in UM) it's an id of a source site.

originMetaSiteId

A template identifier (empty if not created from a template).

originTemplateId

ownerId

siteName

SiteCreated

SiteCreatedContext

Soft deletion of the meta site. Could be restored.

SiteDeleted

Hard deletion of the meta site.

Could not be restored. Therefore it's desirable to cleanup data.

SiteHardDeleted

SiteMarkedAsTemplate

SiteMarkedAsWixSite

First publish of a meta site. Or subsequent publish after unpublish.

SitePublished

Rename of the site. Meaning, free public url has been changed as well.

newSiteName

oldSiteName

SiteRenamed

A new owner id (user that accepts meta site).

newOwnerId

A previous owner id (user that transfers meta site).

oldOwnerId

SiteTransferred

SiteUndeleted

A list of URLs previously associated with the meta site.

urls

SiteUnpublished

StudioAssigned

StudioUnassigned

Empty

value

Int64Value

StringValue

nanos

seconds

Timestamp

DefaultDeliveryProfileSetup

GetCatalogVersionRequest

The version of Stores Catalog installed on a site.

catalogVersion

GetCatalogVersionResponse

InstallBassAppDependencyRequest

InstallBassAppDependencyResponse

Version of the catalog this store was provisioned on. DO NOT USE unless part of the install flow

createdDate

Revision number, which increments by 1 each time the Provision is updated.
To prevent conflicting changes,
the current revision must be passed when updating the Provision.
Ignored when creating a Provision.