Stable: the published Catalog REST API contract is preserved as the API evolves. See REST API Evolution and Compatibility Policy for the compatibility guarantees and the Changelog for changes and bug fixes.
The Catalog REST API is used to integrate external systems with Sales Layer catalog data.
It exposes resources such as products, variants, categories, attribute sets, custom entities, metadata, and changelogs. These endpoints are useful for integrations that need to read catalog information, synchronize changes, or create and update catalog records from another system.
Use this API when Sales Layer is part of a wider product information flow involving ecommerce platforms, ERPs, marketplaces, DAM systems, supplier systems, translation workflows, or reporting tools.
| Area | What it represents |
|---|---|
| Products | Core product records managed in Sales Layer. |
| Variants | Product variant records associated with products. |
| Categories | Category structures used to organize catalog information. |
| Attribute sets | Attribute set definitions used to group product data requirements. |
| Custom entities | Customer-specific catalog entities and their items. |
| Metadata | JSON schema-style information that describes available fields and relationships. |
| Changelogs | Change history that helps integrations detect updates over time. |
Use the Catalog REST API to:
- Retrieve products, variants, categories, and custom entity items for downstream systems.
- Filter and paginate catalog data for synchronization jobs.
- Create, update, or delete catalog records when the integration owns that workflow.
- Retrieve metadata so an integration can understand available fields before building requests.
- Read changelogs to detect what changed since a previous synchronization.
- Access product data in the context of categories or attribute sets.
Metadata endpoints describe the structure of catalog resources. They help integrations discover available fields, relationships, and localized content rules before requesting or writing data.
| Endpoint area | Functional description |
|---|---|
| Catalog metadata | Describes the public catalog model. |
| Product metadata | Describes product fields and relationships. |
| Variant metadata | Describes variant fields and relationships. |
| Category metadata | Describes category fields and relationships. |
| Attribute set metadata | Describes attribute set fields and relationships. |
| Custom entity metadata | Describes custom entity structures by denominator. |
Read endpoints return catalog resources. They support integration patterns such as search, filtering, synchronization, and export.
| Resource | Functional description |
|---|---|
| Attribute sets | List or retrieve attribute set records. |
| Categories | List, filter, or retrieve category records. |
| Custom entities | List, filter, or retrieve custom entity items for a specific custom entity type. |
| Products | List, filter, or retrieve product records. |
| Products in categories | Retrieve products associated with a category. |
| Products in attribute sets | Retrieve products associated with an attribute set. |
| Variants | List, filter, or retrieve variant records. |
| Variants in products | Retrieve variants associated with a product. |
Pending revisions under a legacy approval workflow are excluded from read operations and return 404 Not Found when addressed directly. They cannot be used as a parent category or product and no longer reserve their reference. Deleting an item also deletes its pending revision.
Write endpoints create, update, or delete catalog records. Use them when your integration is responsible for sending controlled changes into Sales Layer.
| Resource | Supported actions |
|---|---|
| Attribute sets | Create, update, and delete attribute sets (available via Attribute Sets v2 endpoints). |
| Categories | Create, update, and delete categories. |
| Custom entities | Create, update, and delete custom entity items. |
| Products | Create, update, and delete products. |
| Variants | Create, update, and delete variants. |
For categories, products, variants, and custom entity items, the accepted status values are V (visible), I (invisible), and D (draft). Internal values R and X return 400 Bad Request. Resource metadata marks status as required and non-nullable, lists V, I, and D, and declares D as the default (V for attribute sets).
Changelog endpoints help integrations identify changes without reprocessing the full catalog every time.
| Resource | Functional description |
|---|---|
| Categories changelog | Returns changes for categories or a specific category. |
| Custom entities changelog | Returns changes for custom entity items. |
| Products changelog | Returns changes for products or a specific product. |
| Variants changelog | Returns changes for variants or a specific variant. |
The author_type field can also contain api, agent, and unknown. REST API changes are recorded as api; records with no recorded author use unknown. Do not assume that an unrecorded author is a connector.
Layout endpoints retrieve or replace the form layout configuration for a resource type.
| Resource | Functional description |
|---|---|
| Categories layout | Get or update the form layout for categories. |
| Custom entity layout | Get or update the form layout for a specific custom entity type. |
Make sure your integration:
- Sends a valid API key in the
X-API-KEYheader. - Uses metadata endpoints to understand available fields before building dynamic requests.
- Uses filtering and pagination for large catalog reads.
- Uses changelog endpoints for incremental synchronization when possible.
- Applies retry and rate limiting behavior as described in Rate limiting.
- Reviews REST API Evolution and Compatibility Policy before updating generated clients or mappings.
Date and date-time fields, including *_creation, *_modify, and custom date fields, are returned in UTC, in ISO 8601 format with a Z suffix. Date comparisons in $filter and sorting in $orderby use UTC instants. Convert local time to UTC before constructing filters.
Use the Catalog REST API v2.0 OpenAPI reference for request parameters, schemas, examples, and status codes.