Events let another system react after commerce data changes. Use them when an external cache, feed, workflow, or fulfillment system needs to hear about changes without polling Enad on a schedule.

Start here to decide whether webhook delivery fits the job and what your receiver must handle before you enable it. Use the Event catalog for exact event_type strings, base envelope fields, payload schema IDs, and top-level payload field summaries.

Choose the right path

Use this overview to plan webhook scope, receiver authentication, retries, and reconciliation.

Use Events latest when you are implementing the receiver and need delivery states, timeout behavior, retry waits, worker behavior, and a control-flow example.

Use Event catalog when implementation code needs event names, envelope fields, schema IDs, or top-level payload fields. Validate nested payload details against the JSON Schema contract before you map production data.

When events are a good fit

Choose Events when another system can react after Enad records change. Typical jobs include:

• refreshing storefront or CDN caches.
• sending product, price, stock, or content changes into another platform.
• triggering enrichment or indexing work.
• keeping an external system close to Enad state without frequent polling.

Use API reads when the caller needs current state on demand, a backfill, a full reconciliation pass, or endpoint-level request and response contracts. Start from APIs when you need to choose among Management, Shopper, Auth, DAM, Media, and Search.

Use Integrations when the job is to create, verify, inspect, update, run, or stop an integration record or sync job. Use Events when a receiver should react after Enad data changes.

Webhook event families

Webhook integrations use broad enabled_events groups:

Treat this table as a subscription planning aid, not an event-name list. Webhook configuration uses enabled_events values such as attributes, brands, categories, markets, organisations, prices, products, series, stocks, store_groups, tags, users, and variants. The Event catalog lists exact event names, base envelope fields, payload schema IDs, and top-level payload field summaries.

Not every catalog domain is a configurable group. For example, catalog domains such as channel_content, merchant_user, and variant_stock are exact event or payload families, but current webhook configuration uses the accepted enabled_events values above.

Webhook delivery shape

Enad sends each webhook as a JSON POST. The request body contains the event envelope and payload. Receivers should expect:

• Content-Type: application/json
• User-Agent: Enad Webhooks
• X-Correlation-ID when a correlation ID is available
• any custom auth header configured for the webhook integration

The current delivery shape uses the configured custom auth header pair as the receiver authentication mechanism. Do not build a receiver that requires a signature header unless your webhook settings or a delivery reference explicitly provides one.

Keep authentication separate from event parsing. The custom auth header decides whether the request may enter your receiver. The Event catalog and JSON Schema contract decide how accepted bodies get routed and validated.

Do not treat event_type, timestamps, correlation IDs, retry behavior, or payload fields as a signing protocol.

Webhook settings can also include a delivery delay and store-group scope. Use those settings to control timing and store-group context.

Receiver responsibilities

Build the receiver as a small intake layer followed by durable work processing:

• authenticate incoming requests before parsing business data.
• persist or queue accepted deliveries before slow downstream calls.
• route on catalog-backed event_type values.
• validate payloads against the matching schema before mutation.
• return 2xx only after the receiver has safely accepted the delivery.

Retries can create duplicates, so handlers need idempotency. Deliveries can also arrive late or out of order; when order matters, read current Enad state before writing downstream state.

Log unknown event types and unsupported payload versions without taking down the endpoint. Schedule reconciliation so missed, delayed, or failed deliveries do not become permanent drift.

Enad treats a 2xx response as successful delivery. Non-2xx responses and most request failures trigger retries. DNS failures and direct private or loopback IP targets fail permanently.

Retry waits are 10 seconds, 20 seconds, 30 seconds, 1 minute, 5 minutes, 10 minutes, 30 minutes, and 60 minutes.

Where to go next

• Events latest - implement receiver authentication, retries, delivery states, and safe intake flow.
• Event catalog - copy exact event_type strings, envelope fields, schema IDs, and top-level payload fields.
• Integrations - configure and operate integration records and sync jobs.
• APIs - choose an API family for current state, backfills, or endpoint-level contracts.