Integrations

Route-selection guide for Enad integrations, webhooks, APIs, SDKs, Search, Media, and agent routes.

Start here to choose the Enad surface that matches the integration job. Most integrations combine direct API reads or writes, webhook-driven change handling, package-supported application code, and reference pages for exact contracts.

Choose the right surface

React to commerce data changes: start with Events. Webhooks fit downstream sync and cache refresh jobs.
Create, update, or manage merchant data: start with Management API. Administrative workflows need authenticated Management API contracts.
Build storefront discovery, listings, facets, or autocomplete: start with Search. Search GraphQL is the preferred surface for new storefront read and discovery work.
Maintain existing public REST catalog reads: start with Shopper API. Use it only when an existing client still needs the REST contract.
Add login, carts, orders, or wishlists: start with Auth API. Shopper account and session flows belong to the Auth API track.
Upload, organize, or serve assets: start with Media. DAM and Media routes separate asset management from image delivery.
Use package-supported helpers: start with TypeScript SDK or React SDK. SDK guides explain imports, provider setup, generated types, and React composition.
Route agent work: start with Agent guides. Agent guides point tools at the right Enad surface before they read or write.

Common integration patterns

Source system to Enad

Use the Management API when an ERP, PIM, or operations tool needs to write managed data into Enad. Pair authored guidance with OpenAPI reference whenever exact paths, request bodies, parameters, or response schemas matter.

Integration management

Use the integration-management surface when an app needs to register, inspect, verify, or operate an integration record. It does not replace the Management API for commerce writes or Events for delivery.

The Integrations API has four groups:

Manage records: list, create, get, update, and delete integrations for an app.
Verify setup: run setup verification for the stored connector configuration.
Inspect health or usage: read app stats or integration stats.
Run synchronization: create, inspect, or stop a sync job.

Keep this surface separate from event delivery. Integration management controls records and sync workflows; Events explain webhook-driven reactions after commerce data changes. Use the Integrations reference or Integrations OpenAPI for exact paths, parameters, request bodies, response fields, and sync payload details.

Contract facts to keep in mind

Use these facts to choose the right reference. Use operation pages for exact paths, parameters, request bodies, response fields, and sync payload details.

Integration records are app-scoped. Create and update requests validate the integration type, run the type-specific configuration validator, and store normalized settings.
List responses omit settings; detail and write responses include settings with secret values masked.
Update merges the supplied configuration into the existing configuration before validation.
Create, update, and delete operations publish integration lifecycle events.
Stats are job-processing stats.
Connector integrations that include a rate_limit setting use it to throttle outbound connector work before Enad calls the third-party system.
Connector throttling applies while connector handlers perform outbound third-party work. Connector rate_limit is not a global Enad API quota.
Do not treat connector rate_limit as webhook delivery throttling.
Connector types without a verification handler return the operation error, so verify support per connector before building a uniform verification UI.
Search GraphQL is the preferred surface for new storefront reads and discovery. Shopper API remains a deprecated REST compatibility surface for existing public catalog clients.

Sync jobs and webhooks

Sync creation assigns a shared sync_id and stores the requested sync work for background processing. The initial response identifies the sync request, but it is not the progress source. Poll the status route for pending, processing, completed, failed, and to-be-retried counts instead of assuming the create call has already produced outbound jobs.

Price sync targets variant/store-group price pairs instead of a single generic item ID list. Stopping a sync deletes jobs for that sync_id only when they are still pending or waiting to be retried.

Use Events when downstream systems need to react after Enad data changes. Webhook configuration uses enabled_events values such as attributes, brands, categories, markets, organisations, prices, products, series, stocks, store_groups, tags, users, and variants. Delivery records move through pending, processing, completed, failed, and to-be-retried; use Events latest for retry waits, timeout behavior, and retention guidance.

Find exact details

Use guides to choose the Enad integration surface. Use references and package guides for exact contracts:

API endpoint paths, parameters, request bodies, responses, enums, and auth schemes come from OpenAPI references.
Integration record, verification, stats, and sync-job endpoint details come from the Integrations reference.
SDK imports, props, hooks, generated types, and runtime behavior come from package guides.
Search GraphQL fields, variables, fragments, and operation shapes come from Search schema references.
Event type strings must come from Event catalog, and payload fields must come from payload schemas. Webhook delivery behavior is covered by Events latest, while app-specific endpoint, auth header, delay, and store-group settings come from the configured integration.

Treat examples as implementation guidance unless the reference or package docs confirm the exact field, method, enum, or payload shape.