iso8601 formatted date string (YYYY-MM-DDT00:00:00) in UTC
API Specifications
/Returns Management
/- POST a unit's final disposition
Real Time Inventory Receipt API
Create Inventory Receipt
Drop Ship
Introduction
Post Confirmation:
Post Cancellation:
Post Partial Cancellation:
Failure Handling
POST a Drop Shipment Confirmation
POST a Drop Shipment Cancellation
POST a Drop Shipment Partial Cancellation
Disposition Update
Introduction
Failure Handling
POST a unit's disposition update
Final Disposition
Introduction
Failure Handling
Outbound ASN
Failure Handling
Outbound ASN Event
POST a unit's final dispo...
Final Disposition (1.0.0)
The Final Disposition API is used to communicate to the client the final state, or disposition, of a unit when it leaves the ROP and is placed in its highest possible value disposition. For example, an unused, open box unit being returned to stock as a final disposition.
When Optoro receives a 401 HTTP status, Optoro will request a new Authentication Token from the client’s services and retry the request.
When Optoro receives any other error (as described above and identified by a 4xx (not 401) or 5xx range http status code) Optoro will retry five times with the same message. The retries will happen at an exponential backoff cadence in order not to overload machines. If the failure persists, the message will be stored in a failure queue and Optoro will have a technical contact person reach out to client tech support to report a problem. When the problem has been resolved, Optoro can manually retry failed requests.
For Final Disposition acknowledgement, all errors are handled the same since this is not in a user facing flow. However, the differentiation of status codes will help Optoro when reporting an issue.
Download OpenAPI description
Overview
Languages
Servers
Mock server
https://developer.optoro.com/_mock/openapi/final_disposition/openapi
https://developer.optoro.com
Bodyapplication/jsonrequired
A flag indicating which channel this pallet is designated for. Possible values are: b2b, d2c, client_liquidation, destroy, dispose, donate, outlets, recycle, removed, rts, rts_drop_ship, rtv, stock_transfer
Example: "rts"
Shared storage location identifier (lot name, present in both Optoro and client’s system) representing the units final location
Example: "RTS-1112"
Indicates the warehouse where the unit was located. Identifier can be configured by the client; otherwise will default to Optoro’s internal warehouse identifier.
Example: "22"
Either a client-provided program name or OptiTurn’s internal program id
Example: "parcel_returns"
[N, TT, R, A, B, C, X] final condition value, a condition mapping is often created to match your internal conditions
Enum"N""TT""R""A""B""C""X"
Example: "N"
A client-provided identifier for the unit, likely provided by an inbound integration
Example: "Unit A"
The identifier of the store that returned the unit to the warehouse
Example: "Store A"
The cause of the disposition event. Currently only populated for remove and dispose events. See below for available values.
| Remove | Dispose |
|---|---|
|
|
Example: "no_item_in_box"
- Mock serverhttps://developer.optoro.com/_mock/openapi/final_disposition/openapi/final_dispositions
- https://developer.optoro.com/final_dispositions
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X POST \
https://developer.optoro.com/_mock/openapi/final_disposition/openapi/final_dispositions \
-H 'Content-Type: application/json' \
-d '{
"disposition": "rts",
"timestamp": "2018-03-20T00:00:00",
"location_identifier": "RTS-1112",
"warehouse_identifier": "22",
"optiturn_lp": "LPAA1234567",
"program_identifier": "parcel_returns",
"sku": "012344566700",
"upc": "0123456789012",
"condition": "N",
"reference_unit_identifier": "Unit A",
"store_identifier": "Store A",
"reason": "no_item_in_box",
"shipment_reference_identifier": "1"
}'Response
application/json
{ "message": "Success" }