What's new in the REST API
Summary of recent evolutions already rolled out on the API and reflected in this documentation.
September 2026 — Full and selective bulk image deletion New
New write operation on the plural image route. The existing single-image delete keeps its contract.
DELETE /api2/products/imagens with delete_all: true removes every image of a product.items mode removes specific images from several products in one call.- Up to 50 products and 500 unique
image_idsper request. - Ownership validation: each
image_idmust belong to the given product. - Already absent IDs are counted in
already_absent_count, without error. - Bulk deletion is global and does not take
store_id. - Requires the
products/imagespermission. DELETE /api2/products/imagemremains available to remove one image per call.
See in detail
Full contract on Catalog › Images.
September 2026 — Product image lookup and inventory New
Release of the read-only product image GET endpoints, already validated in production. The change is additive: the image upload, update and delete endpoints keep their existing contract.
GET /api2/products/imagemLists the images of a product by SKU or ID, with roles, label, position and disabled.GET /api2/products/imagensGlobal image inventory of the catalog for initial load and full reconciliation.has_next and next_cursor, with no page or offset.- Explicit
store_idsupport;0is the administrative/global scope. - Returns the
image,small_imageandthumbnailroles;types=[]is valid. - Disabled images are included with
disabled=true. - An existing product with no images returns
200withimages=[]; a missing product returns404. - The new GETs use the
products/readpermission and are read-only: they do not touch the product, gallery, queue or indexes. - Image updates use
PUT;PATCHresponds405. The documentation has been corrected.
See in detail
Full technical documentation on the new Catalog › Images page. The Postman collection was updated with the three new requests.
September 2026 — Enriched catalog lookups New
Release of the certified product, price and stock lookups. The change is additive: no create, update, delete, queue or listing endpoint was altered.
GET /api2/products now includes human-readable references, a pricing summary and an inventory summary.GET /api2/priceDetailed price lookup with an explicit store and customer group context.GET /api2/stockDetailed stock configuration lookup, including effective salability.- The single product lookup now responds with HTTP
200. - The new GET endpoints are read-only: they neither enqueue work nor trigger reindexing.
- Configurable products expose the indexed price range where applicable and never artificially aggregate the quantity of associated products.
- Historical fields remain unchanged — the enriched objects are additive.
Recent API improvements
Main deliveries that reinforced stability, security and predictability of the API.
- Higher robustness on queue-based stock and pricing processing.
- Clearer validation for invalid fields, attributes and values on product update.
- Improved semantics for
partial_success. - Leaner and more selective reindex.
- Hardening of OAuth, auditing and operational endpoints.
New capabilities already available
client_secret with protected storage and admin masking.invalid_fields, invalid_attributes and invalid_attribute_values.Products endpoint evolutions
Three recent improvements make GET /api2/products more deterministic in multi-store setups and more efficient for batch syncs.
store_idExplicit store selection in multi-store environments.total, last_page and has_next via include_pagination=1.limitDefault 20, max 200, invalid values normalized.See in detail
Full technical documentation on the Products page.
Categories endpoint evolutions New
GET /api2/category now supports paginated listing with the same guarantees already available on the products endpoint. The full category tree can be walked without fetching one category at a time.
GET /api2/category returns all categories with predictable pagination.limitDefault 20, max 200, invalid values normalized.store_idExplicit, deterministic multi-store context.total, last_page and has_next via include_pagination=1.?id=61 preserved for single fetch.?page=N walks the tree safely.See in detail
Full technical documentation on the Categories page.