Amazon Direct Fulfillment order lifecycle: every clock, in order

How Direct Fulfillment differs

The order is Amazon’s, the shipment is yours

In Vendor Central retail, Amazon buys inventory on a purchase order and ships it from its own fulfillment centers. In Direct Fulfillment, Amazon still sells at a price it sets and still handles customer service, but each customer order becomes a purchase order routed to your warehouse, and you ship it directly to the buyer. Amazon supplies the shipping label on its own carrier account and tells you which ship method to use. You never see a cart, a checkout, or a customer message; you see purchase orders with a ship-to address, a required ship date, and a promised delivery date.

That structure is why the program is so strict. Amazon has already promised the customer a delivery date when your PO arrives. Every deadline below exists to protect that promise, and every deadline is measured by Amazon’s systems automatically. Nobody reviews a late acknowledgment; the clock does. The DF vs Vendor Central vs Seller Central comparison covers how to choose between the programs; this page assumes you are in DF and need to run it cleanly.

Step 1

The purchase order arrives, with two dates that matter

Amazon creates one PO per customer order and exposes it through the Vendor Direct Fulfillment Orders API (getOrders and getOrder) or as an EDI 850. Because the PO carries the customer’s name and ship-to address, the API calls are restricted operations: your application needs a Restricted Data Token (RDT) from the Tokens API to read them. An integration that fetches orders on a plain access token will get PO numbers with the PII blanked, which is the single most common “orders are missing addresses” ticket in DF.

Two fields on the PO set every downstream clock. requiredShipDate is the last date the order may leave your warehouse. promisedDeliveryDate is what Amazon told the customer. Amazon also specifies the ship method (the carrier service level) in the PO; you do not choose it, and shipping on a different method is its own chargeback. Read all three on every order, not just the item lines.

Step 2

Acknowledge within 24 hours, accept or reject the whole order

Amazon expects the acknowledgment as fast as possible and no later than 24 hours after the PO is created. It must cover every line item on the PO. Direct Fulfillment is fill or kill: you accept the entire order or reject it, and partial acknowledgments are not accepted. There is no backorder code on DF the way there is on retail POs, because the customer is waiting.

Practical rule: the acknowledgment should be generated by your inventory, not by a person. If available-to-sell for the SKU is positive, accept; if not, reject with 03 immediately rather than waiting to see whether stock arrives. A rejection at hour one costs you a fill-failure mark. A rejection at hour twenty-three costs the same mark plus an angrier customer, and an acceptance you cannot ship becomes a floor denial, which is worse. In InfiPlex the acknowledgment fires automatically off the shared inventory pool as each DF order is pulled, so this step has no human in it.

Step 3

Pick, pack, and print the label Amazon issued

Direct Fulfillment labels come from Amazon, not from your carrier accounts. You call createShippingLabels on the Vendor Direct Fulfillment Shipping API with the PO number, the package dimensions and weight, and the item list; Amazon returns the label on the ship method it specified, on its own carrier contract. The packing slip comes from getPackingSlip. If you ship on a label from your own UPS or FedEx account instead, you have created a ship method mismatch and, depending on the carrier, an order Amazon may not be able to track.

Multi-carton orders are supported: each carton gets its own label and appears as a separate package on the shipment confirmation. Dimensions and weight have to be real, because Amazon is paying the carrier. Warehouses that run DF through ShipStation, ShipHero, or a 3PL WMS need the label to originate from the Amazon call and flow into the pack station, which is what the ShipStation DF set-up covers.

Step 4

Ship by requiredShipDate and confirm within 4 hours

The carton must leave on or before requiredShipDate. Once it does, Amazon expects a shipment confirmation through submitShipmentConfirmations (or EDI 856) within four hours. The confirmation must include every line on the PO, the ship date, the carrier and tracking number for each package, and an estimated delivery date. It is what updates the customer’s order page from “preparing” to “shipped,” so a late confirmation is visible to the buyer even when the package itself is on time.

If you accepted an order and then could not ship it, that is a floor denial. You still send a shipment confirmation, with shipmentStatus set to FLOOR_DENIAL for the order, and Amazon cancels it on the customer side. Floor denials count against your cancellation rate exactly like fill failures, and they are the more expensive of the two because the customer already waited. The four-hour window is why confirmation should be triggered by the carrier manifest or the WMS ship event, not by an end-of-day batch.

Continuous

Inventory feeds are what keep Steps 2 and 4 clean

Amazon only sends DF orders for items your inventory feed says are available. The Vendor Direct Fulfillment Inventory API (submitInventoryUpdate) is how you tell it. Every fill failure and floor denial traces back to a gap between what the feed said and what the shelf held: a sale on another channel that did not reach Amazon in time, a damaged unit, a count that was never adjusted. Feed frequency is the lever. Hourly is the floor for a DF catalog that also sells on Amazon Seller Central, Walmart, or your own store; near real time is the target.

A buffer helps: publish available minus a per-SKU safety quantity so that a burst of orders across channels does not oversell the last unit. The DF inventory KB article shows the buffer setting; the principle is the same in any OMS. One shared pool across every channel, with DF fed from it continuously, is the entire reason cancellation rates go to zero.

Step 5

Invoice through the Payments API and reconcile

After shipment, submit the invoice through the Vendor Direct Fulfillment Payments API (submitInvoice) or EDI 810, referencing the PO number and matching the item cost on the PO. Vendors are paid on their negotiated vendor terms, not on the 14-day settlement cycle sellers get, so invoice timing determines cash timing. Asynchronous submissions (acknowledgments, confirmations, invoices, inventory) each return a transaction ID; getTransactionStatus tells you whether Amazon accepted the payload, and a rejected transaction is not a submitted document. Poll it.

Automation

How InfiPlex runs this end to end

InfiPlex connects to Vendor Central Direct Fulfillment through the Vendor DF APIs with RDT, or through EDI where a vendor is already set up that way. Orders pull on a short cycle, acknowledgments fire from the shared inventory pool, labels are created through Amazon’s call and land at the pack station or in your WMS, shipment confirmations post from the ship scan, inventory updates push as every channel sells, and invoices post after shipment with the PO cost. DF orders sit in the same queue as Seller Central, Walmart, and Shopify orders, so a warehouse runs one process. Set-up details are in the DF SP-API set-up article; the program page is Amazon Direct Fulfillment integration.

Frequently asked

Questions, answered

The deadlines and codes above are Amazon’s; these are the questions vendors ask in the first month.

Resources

Related pages and references

Already in Direct Fulfillment and fighting the clocks?

Our team has connected Vendor Central Direct Fulfillment accounts through SP-API and EDI for years. Bring your PO volume and your current tooling and we will map where each deadline is slipping. Contact us, email info@infiplex.com, or call 888‑770‑0857.