> Portal Navigation:
> 
> - Append `.md` to any URL under `https://dev.wix.com/docs/` to get its markdown version.
> - Pages are either content pages (article or reference text) or menu pages (a list of links to child pages).
> - To get a menu page, truncate any URL to a parent path and append `.md` (e.g. `https://dev.wix.com/docs/sdk.md`, `https://dev.wix.com/docs/sdk/core-modules.md`).
> - Top-level index of all portals: https://dev.wix.com/docs/llms.txt
> - Full concatenated docs: https://dev.wix.com/docs/llms-full.txt

## Resource: About the Structure of Webhooks

## Article: About the Structure of Webhooks

## Article Link: https://dev.wix.com/docs/api-reference/articles/work-with-wix-apis/platform/about-the-structure-of-webhooks.md

## Article Content:

# About the Structure of Events

Wix APIs support event-driven integrations, allowing you to respond to changes such as create, update, and delete actions. How you handle events depends on the API you use:

- REST API: The REST API delivers events via webhooks.
- JavaScript SDK: The SDKs deliver events using event handlers in your code.

This article describes the structure of events for both REST webhooks and SDK event handlers.

## REST webhook payloads

REST webhook payloads contain a `data` object with the following fields, encoded as a JWT:

| Field | Description |
| :-----| :---------- |
| `eventType`  | The event type. For example: `wix.contacts.v4.contact_merged`. |
| `instanceId` | The app instance ID, which identifies the site where the event occurred. |
| `data`       | [Event data](#event-data) object as a JSON string containing fields specific to the event type. The structure and fields are specific to each webhook. Refer to each webhook's reference for the exact structure and fields. |
| `identity`   | [Identity](#identity) object as a JSON string. |

## SDK event handlers

SDK event handlers pass an event object with the following fields:

| Field | Description |
| :---- | :---------- |
| `metadata` | An object containing event metadata, including `eventType`, `instanceId`, [`identity`](#identity), and other information about the event. The structure and fields are specific to each event. Refer to the event's reference for the exact structure and fields. |
| `entity`   | The state of the affected entity after the event occurs. |
| [`modifiedFields`](#the-modifiedfields-object) | The updated fields and their values before the event occurred. Included for some updated events. |

## Event data

In REST webhooks, the event data is in the `data.data` field.
In SDK events, the event data is in the `event.metadata` field, except for entity data.

The content of the event data varies by event type, but generally includes the following:

- Entity data:
  - For created events, this is the newly created entity.
  - For updated events, this includes the entity after the update and sometimes the updated fields with their previous values.
  - For deleted events, this may include the deleted entity.
- Event context: Additional details about the event, such as when it occurred or the reason for the change.
- Action-specific data: For specific actions like publishing or sending, data relevant to that action.

Refer to the documentation for each event to see the exact structure and fields included in its data.

### The `modifiedFields` object

Some updated events include a `modifiedFields` object. This object contains the values of fields that changed, as they were before the update. Use `modifiedFields` to compare old and new values or to track what changed.

The location of the `modifiedFields` object differs between REST webhooks and SDK events:
- REST webhook payloads: `data.data.updatedEvent.modifiedFields`
- SDK event handlers: `event.modifiedFields`

## Identity

The identity information includes the type and ID of the identity that triggered the event:

| Field name | Description |
| :--------- | :---------- |
| `identityType` | Identity type that triggered this event. Supported values: `ANONYMOUS_VISITOR`, `MEMBER`, `WIX_USER`, `APP`. See [About Identities](https://dev.wix.com/docs/api-reference/articles/authentication/about-identities.md). |
| One of: | |
| `anonymousVisitorId` | Site visitor ID. |
| `memberId` | Site member ID. |
| `wixUserId` | Wix user ID. |
| `appId` | App ID. |


## Account-level webhooks

Enterprise and Channels partners can subscribe to [account-level webhooks](https://dev.wix.com/docs/develop-websites-sdk/code-your-site/account-level-development/about-account-level-webhooks.md) for events such as site creation, folder changes, and team member updates.

For more information, see [About Account-Level Webhooks](https://dev.wix.com/docs/develop-websites-sdk/code-your-site/account-level-development/about-account-level-webhooks.md).

## Legacy webhooks

Some legacy REST webhooks don't follow the standard structure described above. For example, the legacy Wix Stores [Product Changed](https://dev.wix.com/docs/api-reference/business-solutions/stores/catalog-v1/catalog/product-changed.md) webhook returns only the fields that changed with their updated values, in a flat list rather than the full object structure.