Collections group products for commercial purposes — storefronts, promotions, editorial curation — independently of taxonomic categorization (Categories). They support hierarchy (a collection can have child collections via parentId) and manual ordering of their products.
Base path different from /products
This domain lives under /collections, its own API Gateway resource (fenicia-collections-{stage}) — not a sub-resource of /products. Use https://api.fenicia.io/collections/... directly, not /products/collections/....
Authentication: same as the rest of the API — Authorization: Bearer fkapi_..., 401 if the tenant can't be resolved, 403 if the tenant is suspended. All write and read operations additionally require the corresponding collections:* permission.
The filter parameters are confirmed against the source code (they're the same fields supported by CollectionsService.search). The exact pagination envelope (key names) was not verified field by field — confirm it against a real response before depending on its exact shape.
Returns the complete collections tree, or the subtree of a given root
rootIdstring
ID of the subtree's root collection. If omitted, returns the complete tree.
{ "code": "not-found", "message": "Collection not found" }
400
{ "code": "has-children", "message": "Cannot delete collection with children. Delete children first or move them." }
Required permission:collections:delete
Can't delete a collection with children
If the collection has child collections (parentId pointing to it), the deletion is rejected with 400 has-children. Move or delete the child collections first.
collections:* is its own permission group (read, create, update, delete), separate from products:*. A role with read access to products doesn't necessarily have read access to collections — check both if your integration touches both domains.