Use the Shopper API when an existing storefront still depends on Enad's deprecated public REST catalog reads. It covers catalog browsing, product detail, filtering, and redirects without using private Management API credentials.

For new discovery-heavy storefront work and MCP read capabilities, start with the Search API and GraphQL-backed search.* capabilities. Use the Shopper API only when you specifically need the existing public REST catalog endpoints directly.

Use the reference and OpenAPI spec for exact methods, paths, parameters, request bodies, and response schemas.

• API track: Shopper API.
• API version: latest.
• Spec: OpenAPI.
• Reference route: /reference/openapi/shopper-api.
• Playground: /apis/shopper/playground.
• Contract host: shopper-cdn.enad.io.

Use this API for

• Maintaining existing Shopper REST catalog integrations.
• Legacy mobile or headless storefront reads that have not migrated to Search GraphQL.
• Compatibility work where a public catalog client must keep the REST shape.

Do not start new MCP read capabilities on Shopper REST when an equivalent GraphQL-backed search.* capability exists. Route merchant-owned catalog, commerce, media, or identity changes to Management API or another owning api.enad.io API contract.

Choose Auth API when the integration needs customer login, token refresh, account-scoped carts, orders, or wishlists. For new Search GraphQL discovery flows, start with the Search docs and Search reference.

Scoping model

Shopper API routes are scoped to the app and shopper context. The route group validates the app, store group, market, locale, and bearer token before the handler reads catalog data.

https://shopper-cdn.enad.io/api/v1/omni/{app_id}/{store_group}/{market}/{locale}

• app_id: selects the app whose catalog is being read, keeping requests attached to the correct storefront app.
• store_group: selects the storefront grouping used for catalog relationships.
• market: selects the market slug for availability and pricing context.
• locale: selects the language code for localized names, labels, and display content.

When an operation path shows a colon-prefixed variable such as :app_id, treat it as a path variable and replace it with the real app value before making requests.

The app ID must be a valid UUID. The store group and market slugs must resolve inside that app. The locale must be one of the app's available languages or default language. Treat a context mismatch as a request setup problem before changing endpoint shape.

Read areas

Shopper REST is read-only. It covers:

• Categories: flat lists, tree navigation, slugs, URI reads, and category products.
• Products: lists, search, SKU reads, slugs, and related data.
• Brands: brand lists plus ID or slug reads.
• Collections: collection lists, slugs, URI reads, children, and products.
• Redirects: storefront redirect lookup.
• Series: series lists plus ID or slug reads.
• Tags: tag lists plus ID or key reads.
• Variants: lists and search.
• Facets: filter metadata for storefront discovery.

The contract is intentionally read-only. If the job creates, updates, deletes, syncs, uploads, or administers data, leave Shopper and use the Management, Auth, DAM, or Integrations reference for the owning operation.

Authentication and public-read access

Shopper is public-read, not unauthenticated. The current route group expects an Authorization: Bearer ... token that is valid for the app in the route. App, store-group, market, locale, and bearer checks run before product, variant, category, collection, facet, redirect, brand, series, or tag handlers read data. Do not put Management API keys into Shopper API clients. Use the app-scoped storefront/read token configured for this surface, and keep any private token issuance or exchange on the server side.

If a storefront needs authenticated customer context, use the Auth API for login and token handling, then confirm any per-operation requirements in the reference.

Contract facts to keep in mind

Use these facts to choose the right operation. Use endpoint pages for exact parameter names, allowed sort values, pagination caps, response fields, and error shapes.

• Shopper REST is read-only. It covers catalog lists, product detail, filtering, redirects, series, tags, variants, and facets for older storefronts.
• Product and variant listing filters can use shopper catalog dimensions such as SKUs, slugs, categories, collections, tags, brands, series, stock, price, attributes, static lists, smart lists, and child-category inclusion.
• Category detail reads can return paginated products and can optionally include products from child categories.
• Facet requests can be narrowed by category IDs, collection IDs, SKUs, search text, variant inclusion, available-only filtering, and child-category inclusion.
• Invalid pagination values and values over the route cap are rejected before the handler returns data.
• Attribute filters use the shopper REST filter grammar from the endpoint contract. Do not copy Search GraphQL filter objects into Shopper REST query strings.
• Price and stock filters are interpreted inside the route's market and store-group context.
• Use Search GraphQL facets for new discovery UI unless a legacy client requires Shopper REST facet shape.

Keep shopper context explicit: app, store group, market, and locale should come from your storefront routing or session model rather than hard-coded defaults. Treat market and locale changes as cache-key changes.

Playground and reference

• Shopper API playground loads /swagger/shopper-api.json and lets you test current operations interactively.
• Shopper OpenAPI reference exposes the complete family contract.
• OpenAPI specs index lists the available API contracts.

Version behavior

latest moves with the current recommended Shopper API contract. Existing integrations should pin to a specific version route once archived versions are published.