Two additions, both driven by the first shop plugin built on this API — and by the request count of a first sync.
images in POST /v1/products, PUT and the batch#
A product's image URLs can now travel with the product:
{ "external_id": "ERP-1001", "…": "…",
"images": ["https://cdn.example.com/erp/mtb-front.jpg"] }
Until now images needed their own call per product, so the first sync of a
2 000-product catalogue was two batches plus 2 000 image requests — most of a day's
rate limit. With images in the payload it is two batches.
The rules are the ones attributes already has: sent, the list replaces the
listing's images (an identical list changes nothing, so a re-push does not churn them);
omitted, they are left alone. Every entry must be an http(s) URL — a bad one is
invalid_image_url naming its position, rather than being dropped and the listing
published with an image missing. At most 20 per product.
POST /v1/products/{id}/images stays, for multipart uploads.
POST /v1/products/{id}/archive and /unarchive#
Setting stock to 0 never took a product off the marketplace: the listing stayed
visible, just unbuyable. Archiving does — out of search, the storefront and carts —
the same way the seller's own "disable ad" does, so a Biklo order cancelled later does
not republish it. unarchive puts it back on sale — including a product a Biklo order
marked sold, once that order is delivered — and is refused with product_reserved
(409) only while an order for the product is still in progress.
Both are idempotent and need products.write.