Wix APIs support event-driven integrations, allowing your to respond to changes such as create, update, and delete actions. Events are handled differently depending on the API you're using:
The rest of this article describes the structure of REST webhooks. You can find the structure of SDK events in the API documentation.
Most webhooks are organized in a standardized format, as described below. Wix also has some legacy webhooks that don't comply with the standardized format.
The majority of webhooks exposed by Wix align with the standardized format described below.
The data payload consists of the following information encoded as a JWT:
| Field name | Description |
|---|---|
data | |
data.eventType | Webhook event type, as documented in each webhook. For example: wix.contacts.v4.contact_merged. |
data.instanceId | App instance ID, the identifier of the site where the event occurred. |
data.data | Data payload as stringified JSON containing fields specific to the event type. Fields vary by webhook and are documented in each individual webhook reference. |
data.identity | Identity data as stringified JSON. |
The data.identity payload includes the type and ID of the identity that triggered the event:
| Field name | Description |
|---|---|
data.identity.identityType | Identity type that triggered this event. Supported values: ANONYMOUS_VISITOR, MEMBER, WIX_USER, APP. See Identities. |
| One of: | |
data.identity.anonymousVisitorId | Visitor ID. |
data.identity.memberId | Member ID. |
data.identity.wixUserId | Wix User ID. |
data.identity.appId | App ID. |
Wix also returns some legacy webhooks that don't follow the above standard. For example, the legacy Wix Stores Product Changed webhook only returns the fields that were updated, and these fields are returned in a flat list, not according to the full object structure. We're working to replace these webhooks with new ones that align with the above standard, but in the meantime you may depend on a webhook that doesn't align with the standard structure.