Changelog

Notable documented changes to Sales Layer REST API references and to the Sales Layer MCP Server documentation are listed on this page.

This changelog is intended for API consumers and records relevant API changes, fixes, and documentation updates. Entries are grouped by scope. Numeric entry identifiers identify documentation publications; they are not product versions or a promise of Semantic Versioning for the REST APIs or MCP Server. See REST API Evolution and Compatibility Policy for the REST API compatibility policy.

• DAM REST API v2.0 — Beta
• Catalog REST API v2.0 — Stable
• Sales Layer MCP Server

• Updated the DAM OpenAPI reference to dam_swagger_v2.0.0_20261015.json.
• Documented that POST /images, POST /files, PATCH /images({reference}), and PATCH /files({reference}) do not follow redirects: the URL must point directly at the file, and a URL that answers with a redirect (3xx) is rejected with 400 Bad Request (URL is not accessible. HTTP status: 302 Found). The API behavior has not changed.

• Updated the Catalog OpenAPI reference to catalog_swagger_v2.0.0_20261020.json.

• The reference for PATCH /Products({productId}), PATCH /Categories({categoryId}), PATCH /Variants({variantId}), and PATCH /CustomEntities('{customEntityDenominator}')/item({itemId}) documented a 200 OK response with a body. These operations answer 204 No Content with no body, as they always have; the reference now says so. The API behavior has not changed. A client generated from the OpenAPI document will no longer expect a response body from these operations.
• The request example for PATCH /Variants({variantId}) sent frmt_ref, which cannot be changed and is rejected with 400 Attribute frmt_ref is non assignable. The example now updates frmt_stat.
• The request example of the changelog operations sorted by changedAt, a field that does not exist, and was rejected with 400 Unknown property: 'changedAt'. It now sorts by modified_at.
• The reference for the changelog operations (GET /Products/Changelog, GET /Variants/Changelog, GET /Categories/Changelog, GET /CustomEntities('{customEntityDenominator}')/Changelog, and their single-item variants) now documents the query rules: the fields that can be filtered (id, item_id, modified_at; author_type with eq only; author_id only together with author_type; attribute_id with eq only), that changes cannot be filtered, that $orderby takes a single field (id, item_id, or modified_at) and the most recent entries come first without it, that $top goes from 1 to 100 (default 100) and $skip is 0 or greater, and that $select, $expand, and $skipToken are ignored rather than rejected. The API behavior has not changed.
• The reference for DELETE /Products({productId}) did not say what happens to the product's variants. It now says that they are not deleted: they remain without a product (prod_ref empty) and their modification date is updated. To remove them, delete them first with DELETE /Variants({variantId}). The API behavior has not changed.

• Custom entity names are identifiers and must be passed exactly as list_custom_entities returns them, spaces and capitalization included (for example, Device Families, not DeviceFamilies). list_custom_entities and the description of every entity_name parameter now say so.
• The descriptions of the catalog write tools (create_* and update_* for products, variants, categories, and custom entities) now explain how to write image and file fields.
• The descriptions of update_category, update_product, and update_variant now say that references (cat_ref, prod_ref, frmt_ref) cannot be changed, and update_variant says to change a variant's product with prod_id. get_variants now points to get_product_variants for the variants of a single product.
• Every tool that takes an OData filters string (get_products, get_variants, get_categories, get_custom_entity, get_total_count, get_table_info, search_products, and build_dynamic_query) now describes the same filter syntax that the catalog accepts: comparison and logical operators, field in ('A1', 'B2'), contains, startswith, and endswith written as functions, single-quoted text values, and one language per filter for multilingual fields.
• A filter that uses a function the catalog does not support (length, tolower, toupper, trim, concat, or substringof) now returns an error that lists the supported functions, without querying the catalog.
• The filter syntax described by those tools now says that numbers, IDs, and null are written without quotes (for example, prod_id eq 12).
• The tools now explain how to work with a product's attribute set, which is its typ_id field (titled "Family" in some catalogs): filter with typ_id eq <id>, using the ID from get_attribute_sets, or with typ_id eq null for the products in the default attribute set. create_product and update_product now document typ_id (an attribute set ID, or null for the default attribute set), and get_attribute_sets and get_attribute_set say how to list the products of an attribute set.
• A 414 error (request too long) now gives the length of the request URL and the limit (about 8,000 characters), and explains that a list of values to exclude cannot be split into several calls: query without that condition and discard those items from the results.
• dam_create_file and dam_create_image now say that the file name in the URL may be no longer than 255 characters, extension excluded, and that redirects are not followed: the URL must point directly at the file, and one that answers with a redirect is rejected. The url of dam_update_file and dam_update_image says the same about redirects.
• dam_filter_files and dam_filter_images now say that dates in filter are UTC and are written in ISO 8601 with Z (for example, modifiedOn gt 2026-10-01T08:00:00Z), that a local time must be converted to UTC first, and that an offset such as +02:00 is rejected.
• Every tool that takes an OData filters string now says that catalog dates are UTC: a local time must be converted to UTC first, or the results silently leave out records; a date field is written in full and a day is filtered as a range (for example, prod_date ge 2026-10-20T00:00:00Z and prod_date lt 2026-10-21T00:00:00Z), because a value entered in the app may hold a time other than midnight and a bare date such as 2026-10-20 is rejected; and an offset such as +02:00 is rejected.
• dam_update_image said that the replacement URL had to have the same file name as the image, a restriction the DAM REST API no longer applies. It now says that the URL may have any file name, that the image keeps its reference, and that only its file type cannot change, as dam_update_file already did.
• The changelog tools (get_*_changelog) now describe only the filter and sort fields the Catalog REST API documents (id, item_id, modified_at, author_type, author_id, attribute_id), and no longer suggest user_id, user_name, connector_id, connector_codename, or author_name. A filter that uses author_type or attribute_id with in (...) now returns an error that explains how to get the same result, as or already did, because the catalog currently returns only the first value without an error.
• The changelog tools (get_*_changelog) now say, in their descriptions and at the end of every result with entries, that the catalog changelog records creations and modifications only, not deletions, so an item they list may no longer exist.

• Standard entity names were case-sensitive. A name such as products or variants was treated as a custom entity, so get_entity_fields, get_total_count, and get_entity_counts answered that there was no data, or a count of 0, without querying the catalog. Categories, Products, and Variants are now accepted in any capitalization, singular or plural.
• A custom entity that does not exist was reported as empty: get_total_count, get_entity_counts, and get_table_info returned a count of 0, and the custom entity tools returned a generic "resource not found" error. They now report that the custom entity does not exist and how to find its exact name with list_custom_entities (get_entity_counts lists it under its errors and still counts the other entities). An existing custom entity with no records still returns 0.
• Custom entity tools called with a standard entity name (for example, get_custom_entity with variants) now return an error that points to the matching standard tool (get_variants).
• get_entity_fields answered "No data found, try creating some" when it could not read the entity. It now returns an error saying that the entity's fields could not be read.
• update_product, update_variant, update_category, and update_custom_entity answered "No record with id N exists" whenever the API returned 404, also when the record existed and the API had rejected the data sent (for example, an image or file field whose value is not a file in DAM). They now check whether the record exists. If it does, they return an error with the API's message.
• Image and file fields could not be assigned, changed, or cleared with create_product, update_product, create_variant, update_variant, create_category, and update_category. In a field that is not multilingual, a file name was rejected ("must be an object") and an empty value could not be sent; a multilingual field was sent in a format the API rejects. These fields now take the name of an image or file that already exists in DAM (upload it first with dam_create_image or dam_create_file): one name, several names separated by commas or as an array, or "" to clear the field. A multilingual field takes one value per language (for example, {"es": "photo.jpg", "en": "photo-en.jpg"}) or a single name for the catalog's base language. In create_custom_entity and update_custom_entity, a file name sent as text to a multilingual image or file field is no longer rejected by the preview ("Multilingual field must be object or array").
• create_product, create_variant, and create_category answered "not found" when the API returned 404, without the API's message. They now return the API's message, which names the image or file that is not in DAM.
• update_category ignored an empty value sent to clear a field and still reported the category as updated. It now clears the field.
• A multilingual value sent as a JSON string (for example, "{\"es\": \"Hola\"}" instead of {"es": "Hola"}) was saved as literal text in the catalog's base language, and the catalog write tools reported success. In an image or file field, the API rejected it with "The name contains invalid characters". The catalog write tools now treat such a string as the multilingual value: text, number, image, and file fields store one value per language, and a field that is not multilingual returns the same error as a multilingual object. A language that the field does not have now returns an error that lists the field's languages. Any other text, including text that starts with {, is saved as before.
• build_dynamic_query split a filters value sent as an OData string, which is the form its own description showed, into one condition per character (0 eq 'c' and 1 eq 'o' and …), so the query failed or returned the wrong results. filters now takes either an OData string, sent as-is, or an object of equalities, where an array means "any of" ({"prod_ref": ["A1", "A2"]} → prod_ref in ('A1','A2')). Keys with operator suffixes such as prod_ref__in now return an error that shows the string form, instead of being sent to the API as a field name. The description now shows both forms, the filter syntax the catalog accepts, and no longer uses an example field (status) that does not exist.
• build_dynamic_query sent text values containing a single quote (for example, O'Neil) unescaped, both in filters and in search_term, so the API rejected the query. Single quotes are now doubled ('O''Neil'), as OData requires.
• The changelog tools (get_*_changelog) showed changedAt as the example for sorting and filtering, a field that does not exist, and did not say which fields can be filtered or sorted. They now use modified_at in their examples, list the filterable and sortable fields with their rules (author_id and author_name need author_type; attribute_id takes only eq and a field key of the entity), and limit top to 100. Filters that combine author_type or attribute_id with or, and sorting by more than one field, now return an error that explains how to get the same result, because the catalog currently returns incomplete results for them without an error.
• The changelog tools (get_*_changelog) said that dates had no time zone. modified_at is UTC, so a filter written with the user's local time, such as "changes since 15:00", silently returned fewer entries or none. The tools now say that modified_at is UTC and show it with Z (for example, 2026-10-19T06:55:28Z).
• When the catalog rejected a request, the MCP Server did not pass on the catalog's reason. Read tools answered "Filter syntax appears correct – the field name might not exist", even for a syntax error, and other errors such as 414 (request too long) or 401 (invalid API key) arrived as "Unknown Status… Please contact support". The tools now show the catalog's message as it is, with a hint for common causes (a field that does not exist, a value of the wrong type, text without quotes); a 414 explains how to shorten the query, and a 401 says that the connection's API key is invalid or expired.
• Subcategories could not be created or moved: create_category and update_category sent the parent as cat_parent_ref, which the API rejects. They now take the parent as cat_parent_id, or as cat_parent_ref, which is resolved to its ID; update_category with cat_parent_id: null moves a category to the root. A parent reference that does not exist returns an error and nothing is written.
• update_variant offered a frmt_ref parameter that the API always rejects. It has been removed.
• get_next_page could not be used, because no response included the URL it needs. Paginated reads now end with the exact get_next_page call for the next page, and the pages chain. The following pages now say which items they show (for example, "items 11-17") and mark the last page, instead of repeating the first page's count. The changelog tools now say to repeat the same call with the next skip value.
• get_product_variants with expand_cultures returned the variants' multilingual fields in only one language, without saying so, because the variants of a product were requested in a single language. It now returns every requested language.
• get_product_variants for a product without variants, and get_category_products for a category without products, returned a "resource not found" error. They now say that the product or category exists and has none, and return an error only when the product or category does not exist.
• A filter on a language-specific field (for example, prod_title_en eq 'Coat') was compared against the catalog's base language, so the tools returned other records, or a wrong count, as a normal result. The filter is now compared in the language of the field. Two languages in one filter, or a language the catalog does not have, return an error. The results are still shown in the requested languages.
• get_total_count with a filter that matched nothing answered "Unable to determine total count" and suggested that the entity might not exist. It now returns 0.
• Several examples taught filter syntax that the catalog rejects: contains written as an operator (prod_title_en contains 'Shirt') in the descriptions of get_products, get_variants, and get_categories and in the field reference that read tools return, and, in help_search_multilingual, or across two languages and tolower(). The examples now use valid syntax, and help_search_multilingual suggests one call per language.
• help_search_multilingual built its examples on the entity's title with Spanish and English suffixes (for example, cat_title_es), even when the title is not multilingual in the catalog or the catalog has neither language, so the examples were rejected. It now builds them from the fields and languages the catalog actually has, and for an entity without multilingual fields it explains how to search without a language suffix.
• The field reference returned by get_variants, get_product_variants, and get_custom_entity showed a filter example from another entity (contains(prod_title, …) or contains(cat_title, …)), which is not valid there. The example now uses a field of the response.
• get_products and get_categories silently dropped an expand value they do not support (for example, AttributeSets) and returned the results without it. They now return an error that lists the supported values.
• get_entity_fields and get_table_info listed AttributeSets among the fields of Products, although it cannot be selected, expanded, filtered, or written. It is no longer listed; a product's attribute set is its typ_id field.
• delete_product said that deleting a product also deleted its variants, and confirmed that "the product and all its variants" had been removed. The catalog does not delete them: they remain without a product. The preview and the confirmation now list the product's variants, say that they are not deleted, and explain how to delete them first with delete_variant.
• Clearing a multilingual image or file field with "" cleared it only in the catalog's base language, and the write tools reported the field as updated. "", [], or null now clears the field in all its languages; to clear a single language, send that language only (for example, {"en": ""}). This applies to create_* and update_* for products, variants, categories, and custom entities.
• get_attribute_set, get_category_layout, and get_custom_entity_layout showed only the title of a divider that had both a title and a type, so the type was not visible. Because update_attribute_set, update_category_layout, and update_custom_entity_layout replace the whole layout, writing back a layout read this way reset the divider to the default type. The layout tools now show both the type and the title.

• The Variant schema included in GET /Products/$metadata, GET /Categories/$metadata, and GET /AttributeSets/$metadata named the variant's parent product prod_id, which /Variants does not accept. It now names it prod_clone_id, as GET /$metadata and GET /Variants/$metadata already did.
• POST and PATCH requests on Products, Variants, Categories, and custom entities were rejected with 400 Bad Request when the Accept-Language header named a catalog language with a region (for example, pt-BR), and so was such a language used as a key of a per-language image or file value. These languages are now accepted, in any capitalization.
• Date fields with no value were returned by the Products endpoints as a date in year 1 (for example, 0001-01-01T00:14:00Z) instead of null. They are returned as null again.

• POST /Categories, POST /Products, POST /Variants, POST /CustomEntities('{customEntityDenominator}'), and POST /v2/AttributeSets returned an incorrect URL in the Location header. The header now uses the public base URL, like @readLink and @nextLink (for example, https://api2.saleslayer.com/catalog/Products(58)).
• POST /CustomEntities('{customEntityDenominator}') did not percent-encode the custom entity denominator in the Location header, so denominators with spaces or other reserved characters produced an invalid URL. The denominator is now percent-encoded (for example, CustomEntities('Test%20Location')/Item(2)).
• Changelog endpoints returned an @nextLink that pointed back to the current page (same $skip), so a client following it requested the same page again and again. @nextLink now points to the next page.
• Changelog endpoints called without query options (for example, GET /Products/Changelog) returned the first 100 entries and no @nextLink, even when more entries existed. They now return @nextLink whenever there are more pages.
• Changelog entries recorded at the same time could be repeated on one page and missing from the next when paging with $skip and $top. Entries with the same $orderby value (or the same date, under the default order) are now returned in a stable order, so paging returns each entry exactly once.

• Breaking change: search_products no longer accepts price_min and price_max, because price fields differ per catalog. Use the new filters parameter with the field names returned by get_product_metadata. Calls that still send price_min or price_max return an error that explains how to use filters.
• create_variant and update_variant now accept any Variant attribute of the catalog, passed by its internal name.
• Tools no longer assume fields or formats from a specific catalog. Tool schemas, get_entity_fields, and tool examples now assume only the system fields that every catalog has.
• Write tools now report when a language suffix was ignored because the field is not multilingual in the catalog.

• Catalog write tools failed in catalogs without English. They now use the catalog's base language.
• A numeric reference was treated as an internal ID, so a read could return a different record and a Product could be assigned to a different Category. References are now sent as they are.
• create_category and update_category did not apply all of the attributes sent. They now apply every attribute of the catalog.
• Some invalid values were saved without an error: a number with a decimal comma (for example "15,5") was truncated, and a multilingual object sent to a field that is not multilingual was saved as invalid text. These values are now rejected.
• get_category_products and get_product_variants returned incorrect totals and ignored field selection and language options. They now return the correct totals and apply both.
• get_custom_entity failed on custom entities with multilingual image or file fields, and list_custom_entities did not find custom entities. Both now work with every custom entity.
• search_products with include_variants: true failed whenever it found products. It now returns the products with their variants.
• Updating or deleting a record that does not exist returned an error that suggested trying again. It now returns a clear "not found" message, and no validation error suggests trying again. Error responses from the API that had an unexpected shape were not shown; they are now shown in full.

• Added the REST API Evolution and Compatibility Policy as the site's policy page. It defines Stable and Beta compatibility per API surface and replaces the former Versioning and compatibility guide, whose URL redirects to this page.

• Updated the DAM OpenAPI reference to dam_swagger_v2.0.0_20261001.json.
• All DAM REST API operations are now marked as Beta. The contract may still evolve, and any breaking change will be identified in this changelog.
• Breaking change (Beta): POST /images and POST /files now reject file names longer than 255 characters (extension excluded) with 400 Bad Request. PATCH /images({reference}) and PATCH /files({reference}) are not affected, as a replacement keeps the asset's existing name.
• Documented that createdOn and modifiedOn are returned in UTC, in ISO 8601 format with a Z suffix, and that date values in $filter must be sent in the same format.
• Documented the 255-character file name limit of POST /images and POST /files.
• Fixed the response examples of /images and /files to show dates with the Z suffix.

• createdOn and modifiedOn of assets uploaded from the Sales Layer web app were returned 1–2 hours ahead of the actual UTC time. They are now returned in UTC.
• Date comparisons in $filter (for example modifiedOn gt 2026-10-01T08:00:00Z) were offset by 1–2 hours. They are now evaluated as UTC instants.
• Assets created or updated through the DAM REST API were shown in the Sales Layer web app 1–2 hours earlier than their actual time.
• PATCH /files({reference}) did not update modifiedOn.
• POST /images, POST /files, PATCH /images({reference}) and PATCH /files({reference}) returned 500 Internal Server Error when the source URL passed the reachability check but the download then failed (for example, an expired signed URL or a 404 on download). They now return 400 Bad Request with the documented URL is not accessible… message.

• In $metadata, the status field of each resource (cat_stat, prod_stat, frmt_stat, typ_stat, and the status field of custom entities) is no longer nullable and is now listed as required.
• Changelog endpoints can now return author_type values api, agent, and unknown. Changes made through the REST API are recorded with author_type api. Changelog records with no recorded author, previously returned with author_type connector, are now returned with author_type unknown.

• Date and date-time fields (*_creation, *_modify, and custom date fields) were returned without a time zone, and values entered in the Sales Layer web app were returned in Spain local time. They are now returned in UTC, in ISO 8601 format with a Z suffix, and date comparisons in $filter and sorting in $orderby are evaluated as UTC instants. Deployed on 2026-08-21.
• Requests for an unknown or inaccessible tenant returned 500 Internal Server Error. They now return 401 Unauthorized. Deployed on 2026-08-21.
• POST /v2/AttributeSets, PATCH /v2/AttributeSets({id}), PUT /Categories/layout, and PUT /CustomEntities('{customEntityDenominator}')/layout returned validation failures as plain messages grouped by camelCase field name. They now use the documented ValidationFailureRepresentation shape, like the rest of the Catalog REST API: each failure is an object with PropertyName, ErrorMessage, and AttemptedValue, grouped by PascalCase field name.
• Create and update operations on categories, products, variants, and custom entities accepted the internal status values R and X. They now return 400 Bad Request (for example, Value: R not allowed). The only accepted status values are V (visible), I (invisible), and D (draft).
• $metadata listed R as an accepted status value and as the default one. It now lists V, I, and D, with D as the default (V for attribute sets).
• Pending revisions of items under a legacy approval workflow were returned as additional items by read operations and could be deleted or used as a parent category or product. They are now excluded from all read operations, return 404 Not Found when addressed, and no longer reserve their reference. Deleting an item now also deletes its pending revision.

• Clarified the validation failure shapes in the Error responses guide: entries can be plain messages or objects with PropertyName, ErrorMessage, and AttemptedValue, and some Catalog validation errors are returned as a plain JSON string.
• Updated API overviews, date and error guides, and Postman examples to reflect the current DAM specification and the Catalog updates reported by the team.
• Clarified Stable/Beta compatibility guarantees and the distinction between contract-restoring bug fixes and breaking changes.
• Grouped the API Reference navigation into collapsible DAM REST API and Catalog REST API sections, each containing its overview and endpoint reference.
• Renamed the generated reference titles to DAM endpoint reference and Catalog endpoint reference to distinguish them from the API section names.
• Kept Catalog metadata endpoints within the Catalog reference.

• Updated the DAM OpenAPI reference to dam_swagger_v2.0.0_20260825.json.
• Added file management endpoints for non-image assets (documents, spreadsheets, archives, and more):
  • GET /files — filters, sorts, and paginates non-image files.
  • POST /files — creates a file from a publicly accessible HTTP or HTTPS URL and optional tags.
  • GET /files({reference}) — retrieves a single file by its reference (filename).
  • PATCH /files({reference}) — partially updates a file by replacing its source content and/or tags.
  • DELETE /files({reference}) — deletes a file by its reference. Deletion does not cascade to entities still referencing the file.
• Documented the file-library quota and its 409 Conflict response, separate from the image-library quota.

• PATCH /images({reference}) no longer requires the replacement URL to share the current image's filename. The replacement can use any filename — only its content must match the image's current file type.
• PATCH /images({reference}) no longer clears existing tags when the replacement image is supplied without a tags field. Tags are now left untouched unless the request explicitly includes them.
• POST /images now returns @readLink/@editLink values that address the created image, matching the Location header, instead of echoing the URL the request was posted to.
• Updated apis/dam.md and guides/errors.md to cover the Files resource alongside Images, and corrected the PATCH /images({reference}) description to reflect the removed filename restriction.

• Restructured the DAM REST API v2.0 folder into Images and Files subfolders, matching the Catalog folder pattern.
• Added ready-to-run requests for every DAM write operation: Create image (write), Update image (write), Create file (write), Update file (write), and Delete file (write), plus List files with pagination, Filter files by type, and Get file by reference. The collection now covers all 60 endpoints in the current OpenAPI specifications (previously 53).
• Added the damFileReference environment variable.

• The downloadable environment template (postman/sales-layer-rest-api.postman_environment.json) defined the DAM reference variable as damImageId, which never matched the damImageReference name used by the collection's own requests and by this documentation. It also lacked attributeSetV2Identifier. Both files are now identical and match what the collection actually uses.

• Updated postman/index.md: folder table, environment variables table, recommended first run, and the write-operations table now reflect the Images/Files split and the newly packaged DAM write requests. Documented the manual reference-setting workflow for DAM creates, since — unlike Catalog resources — the server does not generate the identifier.

• Added documentation for the Sales Layer MCP Server.
• Added the MCP Server section with seven pages: overview, quickstart, authentication, access profiles and permissions, tool reference, recipes, and troubleshooting.
• Documented the complete 71-tool Full access catalog, with Read-only exposing the read subset.
• Added dedicated Catalog tools for Categories, Products, Variants, and Custom Entities; Attribute Sets v2; Category and Custom Entity layouts; resource metadata; and Catalog changelogs.
• Added ten DAM tools for listing, retrieving, creating, updating, and deleting images and non-image files.
• Documented the Read-only and Full access profiles, including which tools each one allows.
• Documented confirmation behavior per write tool, including which operations use a two-step flow and which execute on the first call.
• Documented OAuth 2.0 with PKCE, including the manual configuration values for clients without dynamic discovery.
• Documented the remote endpoint required by each supported remote MCP client.

• The site changelog now covers both the REST API references and the MCP Server documentation. Entries are labelled by scope.
• Replaced the generic get_table_items, create_item, update_item, and delete_item guidance with the dedicated entity tools now advertised by the server. The generic tools remain hidden and routable only for backward compatibility.
• Updated MCP recipes, permissions, and safety guidance for dedicated Catalog writes, destructive Attribute Set options, full-layout replacement, and DAM asset lifecycle behavior.

• Added an MCP entry to the navigation bar, between Postman and Changelog.
• Added an MCP Server section to the sidebar, after Guides.
• Added an MCP server section to the llms.txt output.

• The home page now presents the REST APIs and the MCP Server as two integration paths.

• Updated the DAM OpenAPI reference to dam_swagger_v2.0.0_20260730.json.
• Added image creation and update operations:
  • POST /images — creates an image from a publicly accessible HTTP or HTTPS URL and optional tags.
  • PATCH /images({reference}) — partially updates an existing image by replacing its source URL and/or tags.

• X-API-KEY is now marked as required on DAM operations.
• DAM operations now document 403 Forbidden where the API key is authenticated but not allowed to perform the requested operation.
• DAM error response schemas were aligned with the current OpenAPI reference, including validation, unauthorized, forbidden, conflict, and generic error representations.
• Existing DAM operation status codes were updated:
  • GET /images now documents 400, 401, 403, and 500 error responses.
  • GET /images({reference}) now documents 401, 403, 404, and 500 error responses.
  • DELETE /images({reference}) now documents 401, 403, 404, 409, and 500 error responses.

• Updated the Catalog OpenAPI reference to catalog_swagger_v2.0.0_20260730.json.
• Added 403 Forbidden responses to Catalog write and layout operations where defined by the current OpenAPI specification.
• No Catalog endpoint paths were added or removed.

• Updated the published DAM and Catalog wrappers to reference the latest source specifications.
• Updated DAM overview, quickstart, and error guidance to match the current OpenAPI references.
• Updated the Postman documentation page so it no longer claims that the downloadable collection already covers every endpoint in the latest OpenAPI references.

• Updated the Catalog OpenAPI reference to catalog_swagger_v2.0.0_20260708.json.
• Clarified Attribute Sets v2 layout validation for POST /v2/AttributeSets and PATCH /v2/AttributeSets({id}): when productLayout or variantLayout is sent, the layout must include non-null sections, rows, and fields arrays.
• No endpoint paths, parameters, request body schemas, response schemas, or documented HTTP status codes changed from the previous Catalog reference.

• Updated the published Catalog wrapper to reference the latest source specification.

• Updated the Catalog OpenAPI reference to catalog_swagger_v2.0.0_20260630.json.
• Custom Entity layout endpoints now use quoted OData-style denominators:
  • GET /CustomEntities('{customEntityDenominator}')/layout
  • PUT /CustomEntities('{customEntityDenominator}')/layout
• Removed 403 Forbidden from 45 Catalog operations where it is no longer defined. The legacy Attribute Sets read endpoints still document 403.
• Attribute Sets v2 operations now use the shared CollectionRepresentation and EntityRepresentation response schemas in the OpenAPI reference.
• Clarified Attribute Sets v2 creation behavior: when variantLayout is omitted, no Variant layout is created; it can be added later with PATCH /v2/AttributeSets({id}).

• Updated the published Catalog wrapper to reference the latest source specification.
• Corrected the home page DAM example to use /dam/images.
• Aligned DAM overview wording with the currently documented image operations: list, retrieve, and delete.

• Attribute Sets v2 endpoints at /v2/AttributeSets support full CRUD operations for attribute sets:
  • GET /v2/AttributeSets — list all attribute sets
  • POST /v2/AttributeSets — create an attribute set (name required; productLayout, variantLayout optional) using existing attributes only; this operation does not create new attributes
  • GET /v2/AttributeSets({id}) — get an attribute set by identifier (default or a positive integer)
  • PATCH /v2/AttributeSets({id}) — update an attribute set using existing attributes only; this operation does not create new attributes
  • DELETE /v2/AttributeSets({id}) — delete an attribute set; optional deleteAssociatedProductsAndVariants query parameter reassigns or deletes associated products and variants
• Layout endpoints for Categories and Custom Entities allow managing form layout configuration:
  • GET /Categories/layout / PUT /Categories/layout
  • GET /CustomEntities({denominator})/layout / PUT /CustomEntities({denominator})/layout

• Catalog API endpoint paths simplified. The current OpenAPI specification defines Catalog endpoints without the /rest/Catalog/ path segment. The canonical base path is now directly under the catalog prefix:

  Previous path	New canonical path
  /catalog/rest/Catalog/Products	/catalog/Products
  /catalog/rest/Catalog/Categories	/catalog/Categories
  /catalog/rest/Catalog/Variants	/catalog/Variants
  /catalog/rest/Catalog/$metadata	/catalog/$metadata
  (and so on for all Catalog resources)

  Existing integrations continue to work without changes. URLs that include /rest/Catalog/ remain compatible and will continue to be supported. A formal deprecation notice will be issued before backward compatibility is removed. New integrations and updated clients should use the shorter paths defined in the current OpenAPI specification.

• GET /PointsOfSale/$metadata — this endpoint no longer appears in the current OpenAPI specification.

• Corrected DAM image path notation: individual image endpoints use OData-style path parameters (/images({reference})), where reference is the image filename unique per tenant.
• Corrected success response documentation: POST /Products, POST /Variants, and POST /CustomEntities return 200 OK (not 201 Created) on successful creation.
• Updated guides and overview pages to remove references to POST /image and PATCH /image/{id}, which were temporarily removed in v0.7.0.

• The DAM and Catalog REST APIs are documented against the current OpenAPI specifications.
• The supported DAM image endpoints are:
  • GET /image
  • DELETE /image/{id}

• DAM: POST /image and PATCH /image/{id} have been temporarily removed from the documentation and the OpenAPI specification. These endpoints will return in a future version. Until then, image import and image update are not available through the documented API surface.

• Grouped the Catalog endpoint reference in the sidebar by resource (Metadata, Products, Variants, Categories, Custom Entities) using OpenAPI tags. The DAM endpoint reference is grouped under Image.
• Aligned guides, overviews, and examples with the current OpenAPI specifications.

• Expanded the Postman collection to include at least one ready-to-run example of every endpoint in the current specifications (DAM and Catalog).
• Organized requests to match the API reference, labeled write operations, and added scripts that capture created identifiers for full create-read-update-delete lifecycles.
• Updated the environment template: added attributeSetIdentifier and removed sampleImageUrl.

• The DAM REST API is documented against the current OpenAPI specification.
• The supported DAM image endpoints are:
  • GET /image
  • POST /image
  • PATCH /image/{id}
  • DELETE /image/{id}

• Updated endpoint references so the changelog matches the published OpenAPI specification.
• Consolidated image operations under the current DAM paths.

• Added the DELETE endpoint for removing images:
  • DELETE /image/{id}

• Successful deletion returns 204 No Content
• The request is rejected if the image is currently being processed

• 401 Unauthorized — missing API key
• 400 Bad Request — invalid request or invalid identifier
• 404 Not Found — image not found
• 409 Conflict — image is currently being processed

• Improved API documentation for DELETE and PATCH operations
• Removed incorrect fields from the PATCH request body schema in the API documentation

• Added the PATCH endpoint for partially updating images:
  • PATCH /image/{id}

• Rename an image using reference
• Replace tags using tags
• Replace the image source using url

• Successful update returns 204 No Content
• reference and tags can be combined in the same request
• The request is rejected if the image is currently being processed

• 401 Unauthorized — missing API key
• 400 Bad Request — invalid request body or invalid field combinations
• 404 Not Found — image not found
• 409 Conflict — image is currently being processed

• Added the POST endpoint for creating images from public URLs:
  • POST /image

• Supports image creation from a public HTTP or HTTPS URL
• Supports optional tags
• Validates image format, size, dimensions, and request payload

• JPEG
• PNG
• GIF
• TIFF
• WebP
• PSD

• 400 Bad Request — invalid URL, unsupported format, invalid tags, or invalid image constraints
• 401 Unauthorized — missing API key
• 500 Internal Server Error — unexpected processing error

• Added the GET endpoint for listing and filtering images:
  • GET /image

• Supports filtering
• Supports sorting
• Supports pagination
• Supports OData-style query parameters documented in the API reference

• 400 Bad Request — invalid query parameters
• 401 Unauthorized — missing API key

• API reference overview
• REST API Evolution and Compatibility Policy
• Catalog endpoint reference
• DAM endpoint reference