Inbound Shipment Get/Delete, onDock and receivingStarted events in Sandbox

Wednesday, Dec 26, 2018

Inbound Shipment Get, Delete and Inbound Shipment Event Callbacks are Now in Sandbox.

Happy Holidays. As of this evening (12/26/2018), Inbound Shipments Get, Delete and 2 out of 3 Callbacks (‘onDock’ and ‘receivingStarted’) are in sandbox and production. Only one more to go, ‘receivingComplete’.

Inbound Shipment GET and Inbound Shipment Resource Changes

Get for Inbound shipments is now in production and sandbox. This includes both the detail and summary list types. We’ve made a couple of field additions to the API to provide more information to your operations and technical teams:

  • exceptions: allows our associates to indicate what kind of exceptions were required during receiving.
  • started_receiving_at: the date and time we began processing the inbound shipment.
  • not_on_original_shipment: (line_items) if an item wasn’t originally indicated in a shipment, but was included in the box by the vendor, we will use this flag to indicate it.
  • total_cost: (summary only) total cost as calculated from the unit_cost in the item catalog.
  • total_received_cost: (summary only) total cost of received units as calculated from the unit_cost in the item catalog.

Inbound Shipment Delete

Much like the other resources in our API, you can now issue Deletes to the[account_slug]/api/v1/inbound_shipments endpoint. The payload is the same as it for other resources.

  {"customer_identifier": "shipment234523"}

You can submit up to 30 at a time (which is an increase from the 10 we allow for create and update). Expected inventory is changed automatically every time you delete an inbound shipment, and you will continue to get a skuInventoryChange callback with the new expected totals for every impacted sku in the deleted Inbound Shipment. If you make a mistake and need to create the same shipment again, just issue a POST request with the same customer_identifier.

Inbound Shipment Event Callbacks and Data Factory

As events occur in our distribution center against your inbound shipments, we will send you related callbacks. Right now, the ‘onDock’ and ‘receivingStarted’ events are ready to be triggered by the Data Factory. Before we get to the data factory, you must first create a callback to receive the outbound message by issuing a POST request to[account_slug]/api/v1/callbacks with the following payload:

  "url": "",
  "message_type": "inboundShipmentEvent",
  "token": "your very secure token"

Once you’ve created the callback (and you’ve created your inbound shipment), you can issue a POST request to the data factory endpoint,[account_slug]/api/v1/data_factory/inboundShipmentEvent, to trigger an onDock or a receivingStarted event to the data with the following payloads:

  {"customer_identifier":"shipment324324342", "event":"onDock"}


  {"customer_identifier":"shipment324324342", "event":"receivingStarted"}

Data factory requests for Inbound Shipment Events can only be submitted for ‘open’ and ‘onDock’ inbound shipments. If a shipment is open and you issue a ‘receivingStarted’ data factory request, you will receive two notices, one for ‘onDock’ and one for ‘receivingStarted’.

The callback is documented in the api spec at

Search Criteria Meta Data

Our API already returns meta data about the data returned on every GET request, denoting whether or not an item is a summary or a detail, for instance, but we have now begun returning ‘search_criteria’ in every GET request. This will allow you to see what criteria you sent to us. It will appear as below:

    "search_criteria": {
        "status": "all",
        "sdt": null,
        "edt": null
    "limit": 30,
    "offset": 0,
    "list_type": "summary",
    "include_counts": false,
    "data": []