v1.026

Return item details are now sourced from return units.
The receiving_details records returned by GET /v1/integrations/returns and GET /v1/integrations/returns-list for disposed, donated and other non-restocked units are now sourced from the returns processing unit model instead of the legacy Optoro inventory records. All unit-sourced records — including historical records that originated from the legacy Optoro flow — are reported with the return_unit type and are identified by the unit's UUID.

🚀 New Endpoints

None

🛠 Schema & Property Updates

• ReturnItemDetails (receiving_details items on GET /v1/integrations/returns and GET /v1/integrations/returns-list):
  • type (string) — new enum value return_unit (unit processed by the returns flow). The optoro_inventory value is no longer emitted: historical records that previously carried it are now reported as return_unit. 🔴 BREAKING for consumers that validate type against a closed set of values or that match historical records by their optoro_inventory type — accept the new return_unit value.
  • type_scoped_id (integer|null) — now nullable. It stays populated for receive records; it is null for return_unit records, which are identified by their unit_uuid instead. 🔴 BREAKING for consumers that assume the field is always an integer or that used it to identify historical Optoro records.
  • unit_uuid (string|null) — new field carrying the UUID of the return unit the record originates from; present for return_unit records, null for receive records.

📖 Documentation & Constraints Changes

• type and type_scoped_id descriptions updated to explain the new return_unit record source and the UUID-based identification of unit records.

Migration guidance: treat (type, type_scoped_id) as a nullable pair and use unit_uuid as the stable identifier for return_unit records. Historical records sourced from the legacy Optoro flow are re-identified: they now appear as return_unit records with a unit_uuid and no longer expose their legacy optoro_inventory identifiers.