The fitment module answers the question "does this product apply to this vehicle?" — typical for auto parts, where the same SKU can be compatible with multiple combinations of make, model, year, and submodel.
The structure has two levels:
Catalog (FitmentCatalog): defines the hierarchy of compatibility levels for your vertical (for example, Make → Model → Year). A catalog can be marked as isDefault.
Node (FitmentNode): a concrete value within a catalog level (for example, Make = "Nissan", with a child Model node "Sentra"). Nodes form a tree via parentId/parentLevel.
A product is associated with node combinations via fitmentConfig (within the product payload — see Update a product); this domain exposes the endpoints to manage catalogs/nodes and to query compatibility (search, check).
Shape of `dimensions[]` not verified field by field
The compatibility search and check endpoints (/fitment/search, /fitment/check/{sku}) receive a dimensions[] array that references catalog levels and values, but the audit did not confirm the exact shape of each array element. Confirm it against a real response from GET /products/fitment/catalogs/{id}/nodes (the same level/value returned by that endpoint are what's used to build dimensions[]) before integrating.
{ "code": "bad-request", "message": "Level orders must be sequential starting from 0" }
Required permission:products:create
Updates a catalog (partial)
catalogIdstringrequired
Catalog ID.
namestring
New name.
levelsarray
Replaces the levels. Must include at least one.
isDefaultboolean
Marks/unmarks as the default catalog.
{ "name": "Refacciones automotrices MX y CA", "isDefault": true }
404
{ "code": "not-found", "message": "Fitment catalog not found" }
400
{ "code": "bad-request", "message": "At least one level is required" }
Required permission:products:read
RBAC: this write endpoint requires READ, not UPDATE
Unlike the rest of the write operations in this domain, PUT /products/fitment/catalogs/{catalogId} is gated with the products:read permission in the audited source code, without an additional products:update permission. This is a confirmed RBAC inconsistency in the code, not an error in this documentation — report it to support if your integration depends on separating read and write of catalogs by role.
[ { "sku": "REF-PASTILLA-FRENO-01", "title": "Juego de pastillas de freno delanteras", "matchScore": 1 }]
400
{ "code": "bad-request", "message": "Catalog ID is required" }
Required permission: none additional — authentication only (valid Authorization and resolved tenantId). No explicit requirePermission() was confirmed for this endpoint beyond the standard gate by HTTP method.
Checks whether a specific product is compatible with a combination of dimensions
{ "code": "not-found", "message": "Product REF-PASTILLA-FRENO-01 not found" }
Required permission: same case as /fitment/search — no additional explicit requirePermission(), authentication only.
Response shape partially verified
isCompatible and matchScore in POST /products/fitment/check/{sku} are confirmed; additional fields the response might include (for example, the detail of which dimension didn't match) were not verified field by field.
Missing or invalid required field (catalog name/type/levels, duplicate or non-consecutive levels, inconsistent node hierarchy), a required query parameter is missing (level, q), or data is empty in the import.
not-found
404
The requested catalog, node, or product doesn't exist.
auth:invalid_token
401
The API key is invalid or has been revoked.
auth:permission_denied
403
The API key doesn't have the required permission for this operation.