Reference

# Reference Use this section when you need exact API contract details, or when you need the fastest route into the right reference hub before you open a generated endpoint page. ## Start here Use these shortcuts when you want the fastest route into exact truth: - **Mixed product work across storefront and admin boundaries** → [Products](/reference/products) - **Order operations across management and auth boundaries** → [Orders](/reference/orders) - **Identity and authenticated shopper-state work** → [Auth](/reference/auth) - **Search GraphQL query and schema-adjacent guidance** → [Search GraphQL reference](/reference/search-graphql/latest) - **Known family, exact machine-readable contract** → [/reference/openapi](/reference/openapi) This area has two browse patterns: - **Browse by API family** when you already know the owning surface, such as Management, Shopper, Auth, or DAM. - **Browse by domain subject** when you know the job to do, such as Products, Variants, Categories, or Orders, but not yet which API family owns each operation. Most REST pages in this area are generated from source artifacts rather than hand-maintained prose. Generated endpoint pages and imported OpenAPI specs stay authoritative for method, path, parameters, request bodies, and response schemas. Product guides elsewhere in the docs explain workflows and integration choices, but they do not replace the reference contract. > **Check family labels before implementation.** Domain-subject hubs can mix operations from more than one API family. Use the subject hub to find the right operation, then confirm the owning family on the generated endpoint page or imported OpenAPI spec before you implement against it. ## Choose a reference area | Area | Start here | Use it for | | --- | --- | --- | | Popular shortcuts | [Popular reference](/reference/popular-reference) | A compact, curated fast-entry page for the most common hubs before you drill into exact contracts. | | API family hubs | [Management OpenAPI](/reference/openapi/management-api), [Shopper OpenAPI](/reference/openapi/shopper-api), [Auth](/reference/auth), [DAM](/reference/dam) | Start here when you already know which API family owns the work and want the cleanest path to exact contracts. | | Catalog subject hubs | [Products](/reference/products), [variants](/reference/variants), [categories](/reference/categories), [collections](/reference/collections), [brands](/reference/brands) | Subject-oriented hubs for catalog and merchandising work. Some of these hubs currently mix shopper and management operations, so use them to find the job first and the owning family second. | | Commerce subject hubs | [Orders](/reference/orders), [cart](/reference/cart), [wishlist](/reference/wishlist), [bundle rules](/reference/bundle-rules), [tax groups](/reference/taxgroups) | Subject-oriented hubs for shopper and order work. Orders currently mixes auth and management operations; the generated endpoint page still owns the exact contract. | | Users and access | [Auth](/reference/auth), [users](/reference/users), [merchant users](/reference/merchant-users), [organisations](/reference/organisations), [custom roles](/reference/customroles) | Authentication, user records, team or organisation access, and role-related endpoints. | | Media and assets | [DAM](/reference/dam), [files](/reference/files), [folders](/reference/folders), [images](/reference/images), [videos](/reference/videos), [shareable links](/reference/shareable-links) | Asset management and media metadata endpoints. For conceptual DAM guidance, use the Media docs; for fields and contracts, use reference. | | Channels and markets | [Channels](/reference/channels), [markets](/reference/markets), [store groups](/reference/storegroups), [omnichannels](/reference/omnichannels), [translations](/reference/translations), [redirects](/reference/redirects) | Market, channel, localization, routing, and storefront context endpoints. | | Operations | [Scheduling](/reference/scheduling), [logs](/reference/logs) | Operational endpoints that support scheduled work and system visibility. | | OpenAPI specs | [OpenAPI specs](/reference/openapi), [Management](/reference/openapi/management-api), [Shopper](/reference/openapi/shopper-api), [Auth](/reference/openapi/auth-api), [DAM](/reference/openapi/dam-api) | Full imported spec views when you need schema-level details, source examples, or a machine-readable contract. | | Search GraphQL | [Search GraphQL reference](/reference/search-graphql/latest) | Search GraphQL routing guidance, source-of-truth boundaries, SDK helper coverage, and current generated-package fallback guidance. | ## Fast path by question | If the next question is... | Open this first | Why | | --- | --- | --- | | “Which generated product endpoint owns this job?” | [Products](/reference/products) | Product work often crosses shopper and management boundaries, so the generated endpoint page should confirm the owning family. | | “Which generated order endpoint owns this job?” | [Orders](/reference/orders) | Orders currently mix management and auth operations; the generated page is the fastest authority check. | | “What is the exact login or token endpoint?” | [Auth](/reference/auth) | Auth is already grouped around exact endpoint lookup rather than broader workflow prose. | | “I already know the API family and want the raw contract.” | [OpenAPI specs](/reference/openapi) | The imported spec is the fastest path to schema-level details and machine-readable truth. | | “I need Search fields, documents, or schema shape.” | [Search GraphQL reference](/reference/search-graphql/latest) | Search remains its own guidance-plus-artifact boundary and should not be inferred from REST reference pages. | ## Source boundary Use this section for generated reference routing and exact contract lookup. Do not treat nearby prose guides as a substitute for generated endpoint pages or imported OpenAPI artifacts when you need copy-paste-safe request and response details. ## What generated REST pages contain Generated endpoint pages normally include: 1. **Operation summary** from the source artifact 2. **Method and path** with parameterized route placeholders 3. **Parameters** for path, query, and headers 4. **Request body** content type and schema reference when the operation accepts a body 5. **Responses** with status codes, descriptions, and response schemas Endpoint paths use colon-prefixed placeholders for path parameters, for example `:team_slug` or `:app_id`. Replace placeholders with real values from your app, team, market, or resource context before making a request. ## API family sources | API family | Reference route | Imported spec | | --- | --- | --- | | Management API | [Management OpenAPI reference](/reference/openapi/management-api) | management-api.json | | Shopper API | [Shopper OpenAPI reference](/reference/openapi/shopper-api) | shopper-api.json | | Auth API | [Auth endpoint reference](/reference/auth) | auth-api.json | | DAM API | [DAM endpoint reference](/reference/dam) | dam-api.json | | Search GraphQL | [Search GraphQL reference](/reference/search-graphql/latest) | Source-pending in docs-v3; use generated Search package artifacts for exact schema and operation details. | ## Source-of-truth and fallback guidance For REST endpoints, prefer the generated endpoint page for the specific operation. If you need the complete schema graph, examples embedded in the source artifact, or a machine-readable contract, use the imported OpenAPI spec for that API family. For Search GraphQL, the docs-v3 route is reference-compatible guidance, not a generated schema reference. Until a canonical Search schema or introspection artifact is attached here, use generated `enad-packages` Search documents and TypeScript artifacts for exact fields, inputs, enum values, nullability, fragments, and operation shapes. If a prose guide and a generated reference page disagree about a REST endpoint contract, trust the generated reference page and the underlying OpenAPI artifact. Use prose guides for workflow, setup, and integration context; use reference pages and source artifacts for copy-paste-safe request and response details.