Amazon seller-fulfilled 3PL integration
ShipFlow for Amazon
A seller who fulfils their own Amazon orders connects their seller account to the warehouse that ships for them. Unshipped orders become warehouse orders with the buyer's address, shipments go back to Amazon with tracking, and offer quantities follow available stock. Orders fulfilled by Amazon are out of scope; this connection is for seller-fulfilled orders.
What the connection does
- The seller authorises the warehouse's application from Seller Central. ShipFlow stores the resulting refresh token encrypted for that client and never shows it again.
- Every ten minutes ShipFlow reads seller-fulfilled orders that are unshipped or partially shipped and were updated since the last poll, across every marketplace the seller participates in for the region. Each becomes a warehouse order under its Amazon order id, with the ship-to address, the ship service level as the shipping method and the latest ship date as the required ship date.
- Lines are matched to warehouse items by seller SKU, then by the ASIN as a barcode, then by the connection's item links. Anything that cannot be matched is held for a person, never guessed.
- When the warehouse ships, ShipFlow confirms the shipment on the order with carrier, shipping method, tracking number and the items and quantities that left. A partial shipment confirms only those items; the rest is confirmed when it ships. A connection can be set to send the same confirmation as an order fulfillment feed instead.
- When available stock changes for an item on the connection, ShipFlow updates that seller SKU's fulfillment availability quantity. Stock is never read from Amazon into the warehouse. Sending anything back can be switched off by the warehouse for the whole connection; while off, every outbound update is logged as skipped.
- Every poll, confirmation and quantity update is a line in the run log the seller and the warehouse both see, with Amazon's answer when one failed.
How a seller authorises it
| Step | What happens |
|---|---|
| 1 | Open the ShipFlow portal, Integrations, and choose Connect on the Amazon card. Pick the Seller Central region (North America, Europe or Far East). |
| 2 | The browser goes to Seller Central. Sign in with the seller account that owns the listings, review the roles the warehouse application asks for, and choose Authorize. |
| 3 | Seller Central returns the browser to the portal. The connection appears in the connected table with its setup steps: authorisation, marketplaces, orders access and ship-to address access. |
| 4 | Map shipping methods and carriers on the connection, and ask the warehouse to switch sending back on when you are ready for confirmations and quantities to flow. |
If Amazon ever stops accepting the stored authorisation, the connection is marked reconnect required on the seller's card and in the warehouse's view. Reconnect runs the same Seller Central authorisation for the same connection, and item links, the shipping map and history are kept.
Selling Partner API calls used
| API | Endpoint | When ShipFlow uses it |
|---|---|---|
| Login with Amazon | POST api.amazon.com/auth/o2/token | At authorisation: the code from Seller Central becomes a refresh token, stored encrypted for the client. Before every batch of calls: a short-lived access token from that refresh token. |
| Tokens API | POST /tokens/2021-03-01/restrictedDataToken | Every poll: a restricted data token for the ship-to address, which Amazon only releases under the Direct-to-Consumer Shipping role. |
| Sellers API | GET /sellers/v1/marketplaceParticipations | On connect: the marketplaces the seller participates in, so orders are read from all of them in the region. |
| Orders API | GET /orders/v0/orders | Every poll (10 minutes by default): seller-fulfilled orders that are unshipped or partially shipped and were updated since the last poll, with the ship-to. Orders cancelled since the last poll are read the same way. |
| Orders API | GET /orders/v0/orders/{orderId}/orderItems | Per order: seller SKU, ASIN, quantity, order item id and price for each line. |
| Orders API | POST /orders/v0/orders/{orderId}/shipmentConfirmation | When the warehouse ships: carrier, shipping method, tracking number and the order items and quantities that left. One confirmation per shipment, so a partial shipment confirms only what shipped. |
| Feeds API | POST /feeds/2021-06-30/documents and /feeds | Only when a connection is set to confirm shipments by feed: the same shipment as an order fulfillment feed (JSON). |
| Listings Items API | PATCH /listings/2021-08-01/items/{sellerId}/{sku} | When available stock changes for an item on the connection: the fulfillment availability quantity for that seller SKU. |
Nothing else is called. ShipFlow does not create or edit listings, prices or offers beyond the quantity, does not read buyer email or payment data, and reads the ship-to address only for orders it will fulfil.
Cancellations
An order cancelled on Amazon after it reached the warehouse is never cancelled automatically. It appears in the seller's Orders waiting list with the Amazon status, stays there through any retry, and a person releases the warehouse order or keeps it. The same applies to partially shipped orders whose remaining items are cancelled.
Rate limits
Amazon states an allowed rate on every response. ShipFlow keeps a request budget per connection and operation from those headers, waits when the budget is spent, and retries a throttled call. Throttling appears in the run log as a note on a successful run, not as a failure.
Support
Sellers are supported by their warehouse first; the warehouse is supported by 3PL TechFlow at support@3pltechflow.com. See also ShipFlow for Shopify, ShipFlow for Mirakl, the privacy policy and the security overview.