The Purchase Order API is used to create new purchase orders, or to update, cancel, approve or to get information about already created purchase orders. A purchase order will create one or more fulfillment orders. Order API vs. Purchase Order API Our Purchase Order and Order APIs are both used to send fulfillment orders to our warehouses for outbound shipments. The Order API will be sufficient for B2C orders as it would have the necessary fields for standard direct-to-consumer shipments such as the customer’s contact info, ship-to address, SKU and QTY, shipping method, etc. For B2B shipments, most retailers will require additional info to process your Purchase Order. The Purchase Order API will have all the fields available in the Order API, along with additional fields to meet the requirements for these more complex retailer orders. These fields include retailer SKUs, bill-to info, shipping/delivery windows, and more. Another reason to use the PO API would be if you have more complex requirements for B2C shipments, such as printing extra product information (retailer SKU, UPC, custom product descriptions per retailer, etc), or additional order level attributes on custom packing lists. The Orders API is not able to handle these use cases. Important note: By default, if a PO you submit has errors, it will be placed on hold, and a fulfillment order will not be created until the PO is corrected with an update (PUT). We strongly suggest that you avoid this default behavior by adding “doNotPersistOnWarnings”:1 under the root level in the request JSON (ie, directly beneath “purchaseOrderNo” is a good spot). To determine whether a specific post to the PO API was successful, check the JSON response to see that resource.total = 1. If it is 0, then the PO was not created. In that case, v4Errors and/or v4Warnings will contain the issues with the PO that need to be resolved before attempting posting again. Note that resource.total may be 1 and there may be some v4Warnings. An example would be invalid address, which will not prevent the PO from posting. Note: By default, a PO will go into a “needs approval” status, so that you can build a workflow to either approve or cancel POs. The majority of customers choose to bypass this flow and post POs as already approved by passing “isApproved”:1 under “options”.