When to use this. A sub-supplier is any external company a supplier works with as part of
their production network: fabric mills, trim suppliers, printing houses, embroidery workshops,
and similar partners. Suppliers maintain their own library, which brand customers can then view
to gain supply chain visibility. Use these endpoints to create, update, and query that library
on behalf of a supplier organisation, or to read sub-suppliers across organisations your
account has access to.
The workflow
Sub-suppliers belong to a supplier organisation. The typical path is to create the sub-supplier with location and contact details, optionally update or archive it as the relationship evolves, and soft-delete it when it is no longer part of the supply chain.1
Create the sub-supplier
POST /api/organizations/{organizationId}/sub-suppliers to add one or more sub-suppliers
to a specific supplier org, including the primary contact and relation type. Alternatively,
use POST /api/sub-suppliers if your token is already scoped to the supplier org.2
Retrieve or list
GET /api/sub-suppliers/{id} to fetch a single sub-supplier, or GET /api/sub-suppliers
to list them with filters (country, relation type, custom ID, free-text search).3
Update details
PUT /api/sub-suppliers/{id} for a full replace, or PATCH /api/sub-suppliers/{id} for
partial JSON Patch updates (e.g. updating only the website or archiving). Use
PUT /api/sub-suppliers to update multiple sub-suppliers in a single request.4
Archive or delete
Set
state to archived via PUT or PATCH to hide a sub-supplier from active lists
without removing history. Call DELETE /api/sub-suppliers/{id} to soft-delete it and
cascade to its contacts and associated facilities.Walkthrough
Create a sub-supplier in your own organisation withPOST /api/sub-suppliers. The body is an
array: one or many sub-suppliers are created in a single all-or-nothing transaction. If any item
fails validation or its name already exists in the organisation, nothing is created.
id
(UUID): you use it for single-record reads, updates, and deletes.
Field reference
The fields that matter most when creating or updating a sub-supplier:Roles & permissions
Sub-supplier endpoints check thesuppliers permission: read level to list and read, write
level to update, and admin level to create and delete.
- Supplier accounts need, by default, the
SupplierAdminorSupplierUserrole. - Designer (brand) accounts need the Supplier Chain module and, by default, one of the
CompanyAdmin,ComplianceAdmin,ComplianceUser, orSupplierManagerroles.
GET /api/organizations/{organizationId}/sub-suppliers and
POST /api/organizations/{organizationId}/sub-suppliers) also require that you belong to that
supplier organisation (supplier user) or have an active connection to it (designer user).
When things go wrong
Errors use the standard envelope (status: "error", a code, and error.details[]). See
Errors & responses for the full list of codes and how to resolve them.
Common cases:
- 404: the sub-supplier UUID does not exist.
DELETE /api/sub-suppliers/{id}also returns 404 for a sub-supplier that belongs to a different organisation. - 403: the sub-supplier belongs to a different organisation (on reads and updates), your
account does not have an active connection with the supplier org, or it lacks the
supplierspermission. - 400: a required field (
name,countryCode) is missing, or an enum value (relationType,state) is invalid.
What to call next
Facilities
Register production facility locations for a sub-supplier to build out the supply chain map.
Colours
Manage the brand’s reusable colour library that styles and items reference.
Seasons
Create the seasons that styles are filed under: the top-level collection structure.
Supplier connections
Count a brand’s supplier connections and list its open connection requests.
Style contacts
Look up the supplier and contact people assigned to a style.
API Reference
Full parameter and response schemas for all sub-supplier endpoints.