Skip to main content
When to use this. A facility is a physical production location (factory, mill, warehouse, etc.) owned or operated by one of your sub-suppliers. You create facilities under a sub-supplier, assign production process types to them (e.g. Ginning Mill, Knitting Mill), and then reference them in supply-chain mappings and compliance certificates. Use these endpoints to build and maintain that location library.

The workflow

Facilities live under sub-suppliers. The usual path is to locate or create the relevant sub-supplier first, create facilities with their production process types, and then reference them from supply-chain mappings or style-level assignments.
1

Identify the sub-supplier

Facilities always belong to a sub-supplier. Retrieve the sub-supplier’s GUID from GET /api/sub-suppliers: you’ll need it as the subSupplierId path parameter.
2

Create facilities

POST /api/sub-suppliers/{subSupplierId}/facilities with the facility name, country code, at least one processTypeId, and optionally its address. The endpoint accepts an array so multiple facilities can be created in a single all-or-nothing transaction.
3

List and search facilities

GET /api/facilities (every facility in your organisation) or GET /api/sub-suppliers/{subSupplierId}/facilities to filter by country, process type, MID, or free-text search.
4

Update, archive or soft-delete

PATCH /api/facilities/{id} with [{ "op": "replace", "path": "/state", "value": "archived" }] to retire a facility without losing its history, or DELETE /api/facilities/{id} to soft-delete it (the response returns the facility with state: "deleted"; it never appears in reads or list queries again). To change many facilities at once, PUT /api/facilities full-replaces up to 200 in one all-or-nothing request, each item carries the facility id plus every required field, and an item with state: "deleted" is soft-deleted in the same transaction.

Walkthrough

Create a facility for a sub-supplier and assign process types. The body is an array: one or many facilities are created in a single all-or-nothing transaction.
The response wraps the created facilities in the standard envelope. Hold onto each id: supply-chain mappings and certificate associations reference facilities by it.

Field reference

PUT /api/facilities/{id} and the bulk PUT /api/facilities are full replaces and require all mandatory fields on every call (processTypeIds is the exception: null or omitted keeps the current assignments, [] is rejected). Use PATCH /api/facilities/{id} (RFC 6902 JSON Patch) for partial updates: only the fields you send change, the rest keep their current values.

Roles & permissions

Facility endpoints check the suppliers permission: read level to list and read, write level to update, and admin level to create and delete. Facilities are scoped to your own organisation.
  • Designer (brand) accounts need the Supplier Chain module and, by default, one of the CompanyAdmin, ComplianceAdmin, ComplianceUser, or SupplierManager roles.
  • Supplier accounts need, by default, the SupplierAdmin or SupplierUser role.
DELETE /api/facilities/{id} is a soft delete that cascades to the facility’s process-type assignments, certificate associations, and certificate documents. To retire a facility but keep it and its certificates, archive it (state: archived) instead. The same cascade applies to any item sent with state: "deleted" in a bulk PUT /api/facilities, and such a batch needs admin-level suppliers permission.

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 for Facilities: In a bulk PUT /api/facilities, each error points at the item’s position (for example [2].id or [0].processTypeIds[1]). A batch with any unknown id returns 404 before a cross-organisation id is reported as 403, and nothing is written unless every item passes.

What to call next

Size ranges

Define the size ranges that styles and items reference: another supply-chain building block.

Style categories

Organise styles into categories alongside their facility assignments.

Seasons

Create the seasons that styles are filed under: the top-level product structure.

Style supplier facilities

Link a style to the specific supplier facilities it is produced at.

API reference

Full parameter and response details for all Facilities endpoints.