Changelog
Back to All

v1.020

3 months ago

Receiving LPN identifier documentation clarified and validation tightened.
The descriptions of carton and pallet LPN identifiers in the Receiving API (cartons[].lpns / pallets[].lpns and the identifiers arrays on create) were clarified, and the identifier validation rules were tightened: every carton must carry at least one identifier, and identifier values must be unique across all cartons and pallets of a receiving. No endpoints, schemas, or payload shapes were modified.

🚀 New Endpoints

None

🛠 Schema & Property Updates

None

📖 Documentation & Constraints Changes

  • Create Receiving (POST /v1/integrations/receiving), Get Receiving (GET /v1/integrations/receiving) and Receivings List (GET /v1/integrations/receivings-list) — the LPN identifier type / value descriptions were clarified: the SSCC format is spelled out, and the relation to the deprecated line-level sscc field is described.
  • Create Receiving (POST /v1/integrations/receiving) — every entry in cartons[] must now carry at least one identifier (error code INV-003).
  • Create Receiving (POST /v1/integrations/receiving) — identifier values must now be unique across all cartons and pallets of the payload regardless of identifier type. A duplicate between two SSCC identifiers keeps reporting the existing SSCC-003 code; any other duplicate reports the new LPN-001 code.

No endpoints, fields, or types were added or removed; the payload shape is unchanged. Requests that previously sent identifier-less cartons or reused an identifier value across packaging units are now rejected with a 400 response.