Load a Handling Class for editing
Request the canonical condition tree and its readable expression explicitly. The two nested field parameters resolve the direct Warehouse and Product Profile references without loading their own relationships:Request
Response
type and id are always present in an included resource, so request only the additional fields
the control displays. For a grid that needs only Handling Class data, omit both nested field
parameters; the compact references remain available and ShipStream does not load the related
Warehouse or Product Profile records. List responses bulk-load each requested related type once
for the page rather than once per Handling Class.
Build the editor from metadata
Call List Handling Class condition fields when the editor loads. The response describes the shared Product fields and the additionalproduct_profiles selector. Product Profile options are a finite ID-to-name map; save their numeric
IDs in product_profiles condition values.
Fields such as SKU and Product name advertise a value_source instead of embedding every Product.
After the operator types at least two characters, call the advertised endpoint with a bounded limit:
Request
Response
limit and only the fields the control displays; see Selecting Fields.
Save and poll classification
Send the edited condition tree to the Handling Class update endpoint. Omitted fields remain unchanged.Request
200 with no response body. Poll the Handling Class until
classification.status becomes up_to_date. While work is pending, the status may be queued or
processing; a failed classification reports failed.
Condition values store Product Profile IDs. The
referenced_product_profiles response field
exposes the same dependencies as { "type": "ProductProfile", "id": ... } references. Add
fields:referenced_product_profiles=name when the editor needs their labels; the matching
shallow objects are returned in included.ProductProfile.