Events

# Events Events are the webhook-facing part of Enad integrations. Use them when another system needs to react after commerce data changes instead of polling APIs on a schedule. The public event catalog is still source-pending in docs-v3. This route is therefore a planning and routing guide: it explains when events are the right integration shape, what receiver responsibilities to design for, and where exact event type and payload truth must come from once the catalog is attached. ## What this page can tell you today | Need | Use this route for | Source boundary | | --- | --- | --- | | Decide whether to use webhooks | Event-driven integration fit, receiver design, operational expectations | Guidance is safe to use | | Choose event families to ask for | Product, variant, price, stock, and catalog-adjacent domains | Family list is planning-level until catalog source is attached | | Implement exact handlers | Event type strings, payload fields, retry metadata, endpoint registration details | Wait for the canonical event catalog or generated source artifact | | Validate copied code | Header names, signature format, JSON envelope, delivery timing | Do not copy from prose until source-backed reference exists | ## When events are a good fit Use events when your integration needs to respond to changes after they happen: - refresh storefront or CDN caches after catalog changes - send product, price, or stock changes to an ERP, PIM, WMS, POS, or search system - trigger downstream enrichment, indexing, alerts, or reconciliation jobs - keep external systems close to Enad state without frequent polling Use API reads instead when you need the current state on demand, a backfill, a reconciliation pass, or exact endpoint-level contracts. Start from [APIs](/apis) for route selection across Management, Shopper, Auth, DAM, Media, and Search surfaces. ## Event families The current planning-level families are: | Family | Typical integration question | | --- | --- | | Product | Should another system refresh product content or product-page caches? | | Variants | Should variant options or variant availability be synchronized? | | Tags | Should filtering, segmentation, or merchandising rules be refreshed? | | Categories | Should navigation, taxonomy, or category assignments be synchronized? | | Markets | Should market-specific configuration be refreshed? | | Store Groups | Should store-group visibility or grouping logic be refreshed? | | Prices | Should external channels update price displays or price-derived feeds? | | Stocks | Should availability, inventory, or replenishment systems react? | | Brands | Should brand metadata or brand associations be synchronized? | | Series | Should collection, series, or merchandising group membership be refreshed? | Treat this list as routing guidance, not a catalog. Exact event names, subscription keys, payload schemas, and delivery metadata must come from the future source-backed event catalog. ## Receiver responsibilities Even before the event catalog is attached, you can design the receiver safely: - authenticate incoming requests using the configured webhook secret or source-backed signing contract - persist or queue the delivery before doing slow downstream work - make handlers idempotent because retries can create duplicate deliveries - tolerate out-of-order deliveries by reconciling against source-of-truth state when order matters - log unknown event types and payload versions without breaking the whole receiver - run periodic reconciliation jobs so missed or delayed events do not become permanent drift ## Where to go next - [Events latest](/events/latest) — receiver design, source-pending boundaries, and safe implementation patterns. - [Integrations](/integrations) — choose between webhooks, APIs, SDKs, Search, Media, and AI-facing docs. - [APIs](/apis) — choose an API family when you need current state, backfills, or endpoint-level contracts.