Send to Amazon by API: The Fulfillment Inbound v2024-03-20 Workflow, Call by Call

By Bernardo Campelo, Forbes Business Council E-Commerce Leader, Amazon SPN Certified provider, Amazon SP-API authorized partner, and Founder of PrepVia.

As of October 29, 2026, Amazon's current Fulfillment Inbound API is version 2024-03-20, and version 0 is listed as the legacy version. Amazon removed the v0 operations that created plans and shipments, including createInboundShipmentPlan, createInboundShipment and putTransportDetails, on January 21, 2025. Two of the v0 calls that survived are still required: getLabels and getBillOfLading, because, in Amazon's words, they "print box labels, pallet labels, or bills of lading."

That leaves an operations team with a hybrid. The plan, the packing, the placement, the freight and the delivery window run on v2024-03-20. The paper that goes on the boxes and to the truck driver still comes from v0. This guide follows the order Amazon publishes, call by call, and marks where a decision can no longer be undone.

It is written for operations and IT leads deciding whether to build, buy, or hand this to a prep partner that already runs it.

Every date and name below was checked on October 29, 2026 against Amazon's SP-API documentation, its deprecation schedule and its release notes, linked where they first appear. Amazon revises these pages often: check the version table and the deprecation schedule again before you build against them.

What v2024-03-20 Replaced, and What v0 Still Does

The SP-API deprecation schedule lists ten Fulfillment Inbound v0 operations deprecated on April 1, 2024 and removed on January 21, 2025. They were the calls an older integration used to build a shipment from start to finish.

Six v0 operations were not deprecated: getLabels, getBillOfLading, getPrepInstructions, getShipments, getShipmentItemsByShipmentId and getShipmentItems. Amazon says two of them are necessary to create shipments. So the accurate sentence is not "v0 is dead." It is "v0 no longer creates shipments, but v0 still prints the paper."

Amazon's migration guide maps the old calls to the new ones. For a team with v0 logic still in its code, this is the map:

Three structural changes matter more than the names. First, "All POST operations in the new flow are asynchronous and must be followed by getInboundOperationStatus to retrieve their status." The integration has to poll with the operationId before the next step. Second, cancellation moved from the shipment to the inbound plan. Third, there is no "mark as shipped" step anymore.

The API also talks to Send to Amazon, the workflow inside Seller Central, with a condition. Plans created through the API can be opened and edited in Send to Amazon "once placement and transportation options are confirmed." If someone switches to Send to Amazon before those confirmations, Amazon generates new options there and discards the previous ones. On a mixed team, that rule decides who touches a plan and when.

Every v2024-03-20 operation requires the Amazon Fulfillment role, and Amazon's shipment tutorial also asks for the Product Listing role and existing listings. One plan holds up to 1,500 SKUs and up to 10,000 items per SKU, according to the Fulfillment Inbound FAQ.

Before the First Call: Prep Details, Once per MSKU

The first thing a US integration does is not createInboundPlan. Amazon's Fulfillment Inbound API page puts this warning at the top of its key features: "The seller must prep and label all products before they send them to the Amazon fulfillment network in the US. You must call the setPrepDetails operation in order to retrieve prep details with the listPrepDetails operation. Prep details you add in Seller Central are not returned by listPrepDetails."

A team that set prep categories by hand in Seller Central will not get them back from listPrepDetails, so an integration that reads prep through the API has to set it with setPrepDetails first.

Amazon's additional functionality guide explains why this belongs before the plan. Sellers provide this information "once for each MSKU in an Amazon store," Amazon saves it for future shipments, and "the prepCategory you select using this operation can affect what values you can select for prep and label owners, which are required inputs for createInboundPlan." Amazon does not number setPrepDetails as a step in the shipment. Our reading of that sentence is that it is a one-time setup per SKU that has to be in place before the first plan for that SKU, not a step in the middle of each shipment. If prepCategory comes back as FC_PROVIDED, Amazon has set the category and it cannot be changed.

The prep itself is the seller's job. Amazon's tutorial states that starting January 1, 2026, "the prep and item label services will no longer be available for FBA in the Amazon US store." Every unit has to arrive prepped and labeled by the seller or its prep partner. The prep owner and label owner values your code sends are a statement about who did that work. When those values do not match the SKU's category, plan creation stalls, which is the second of the three walls in our guide to why Seller Central won't create an FBA shipment.

Workflow One, Carton Contents Known: Plan, Packing and Box Content

Amazon's tutorial has two workflows. The first applies when carton-level information is known up front, and the tutorial notes that it covers both less-than-truckload and small parcel shipments. Its twelve steps, in Amazon's own names, map to these calls:

Notice where placement sits. In this workflow the boxes are described before Amazon picks destinations. Amazon explains why: when generatePlacementOptions runs without box content, Amazon returns "placement options that are optimized for unit-level data," and those "can differ from the placement options that are generated after you provide box content information." Box data first gives a placement built on the real cartons.

Step 1: createInboundPlan

The plan needs the ship-from address, the Amazon store, a summary of the items and, for partnered LTL, contact information. The item summary "must include MSKU, quantity, and an indication of who will prepare and label the item." Expiration dates and lot codes are optional, with one constraint: "Multiple expiration dates per SKU on a single inbound plan are not supported." A SKU arriving with two expiration dates needs two plans.

The call returns an inboundPlanId; the initial shipment IDs it generates are read later with getShipment. Those shipment IDs are not the ones printed on labels. The ID on the label is the shipmentConfirmationId (for example, FBA1234ABCD), and it only exists after confirmPlacementOption. This is the first place a home-built integration goes wrong, because both values are called a shipment ID.

Step 2: packing options

A packing group is a set of SKUs that can share a box. Amazon lists what separates SKUs into different groups: dangerous goods, "SKU weights and dimensions, prep and labelling requirements, and barcode requirements." The FAQ says listPackingOptions "returns one option because it is designed to provide the most optimized packing solution based on the input criteria."

Step 3: setPackingInformation

This is the box content step, and Amazon puts a warning on it: "If you do not call setPackingInformation, there may be defects in the receiving process and fees for manual processing." For each box, the call carries the packing group ID, the box content source, the contents (items, quantities and prep and label owners) and the box dimensions, weight and quantity.

The content source has three values: BOX_CONTENT_PROVIDED when the contents field is filled, MANUAL_PROCESS when the seller pays Amazon to enter the information at receiving, and BARCODE_2D when 2D barcodes are on the boxes. With the last two, items stay empty, but dimensions, weight and box quantity are still required. The Seller Central side of the same decision, web form, spreadsheet upload or 2D barcode, is covered in our guide to adding box content to an FBA shipment.

Two rules decide how forgiving this step is. If box information changes after placement options were generated, "you must call generatePlacementOptions again prior to calling confirmPlacementOption." And box information cannot be thrown away: "Discarding packing information is not currently supported." The way out is a new plan. For an operations team, this is the argument for sending box contents only after the physical count at the packing station is final.

Workflow One: Placement, Transportation and Delivery Windows

Step 4: placement options

A placement option is a set of destination fulfillment centers and the split of items between them. Each option lists its fees or discounts, an expiration date and its shipment IDs, and Amazon says those fees and discounts are "determined by an algorithm during shipment creation, not calculated using set rates." Options expire, and generatePlacementOptions has to run again when they do. The freight side is in our post on why near-identical shipments get very different partnered-carrier quotes.

Steps 5 and 6: transportation and delivery window options

generateTransportationOptions takes the placement option ID, the shipment ID, the ready-to-ship date and the ship-from address. For pallets it needs the pallet details too: "If pallet information is not included, LTL transportation options are not generated." The result lists every shipping mode and carrier available for each shipment, Amazon-partnered and non-partnered. Partnered options come back with a quote, and Amazon notes that the expiry date and void window are returned only after confirmTransportationOptions.

Amazon's migration guide calls confirming the delivery window before the transportation option "a new requirement in v2024-03-20." The tutorial is explicit: "You must confirm transportation options for all shipment types. For non-partnered shipments, you must also specify a delivery window." Amazon's release notes for December 3, 2025 set the format: "All delivery windows will be set to one calendar week, a set of seven days starting on Sunday and ending on Saturday." What a missed week costs and how discounted and blocked weeks work is in our post on Send to Amazon delivery windows in 2026.

Steps 7 to 9: review, then the confirmations

The list calls only read; the confirmations commit, in order. confirmPlacementOption selects the split and creates the confirmed shipment IDs, and Amazon writes: "This option cannot be reversed after it is selected." Then, for transportation options that carry the program DELIVERY_WINDOW_REQUIRED, the delivery window is confirmed before the transportation option. After confirmTransportationOptions, "new transportation options cannot be generated or confirmed for an inbound plan."

For an Amazon-partnered option, confirmTransportationOptions is also a payment decision. Amazon says the call confirms "that you accept the Amazon-partnered shipping estimate, agree to allow Amazon to charge your account for the shipping cost, and request that the Amazon-partnered carrier ship the inbound shipment." There is a short way back. With a partnered carrier, a small parcel request can be voided within 24 hours of confirmation, and an LTL or FTL request within one hour. "After these time periods expire, your account is charged for the shipping cost." In v2024-03-20 the void happens through cancelInboundPlan, which cancels the whole inbound plan, not only the freight.

Labels, Bill of Lading and Tracking: The v0 Calls That Stayed

Labels come from v0 getLabels, and the shipment ID it expects is the one that trips teams up. Amazon's warning: "The value of shipmentId in the getLabels request must be the shipmentId (from v0) or the shipmentConfirmationId (from v2024-03-20). Do not use the shipmentId from v2024-03-20." For small parcel, each box needs a unique barcode, built by appending U and a six-digit sequence to the shipment ID, so FBA1MMD8D0U000001 is the first box of shipment FBA1MMD8D0.

One sentence in the tutorial matters to anyone who runs a dock from a dashboard: "Retrieving carton labels with getLabels does not change the shipment status to ready_to_ship. For a shipment status to become ready_to_ship, you must generate labels on Send to Amazon." A status screen that waits for READY_TO_SHIP on an API-labeled shipment can wait for a status that, per Amazon's tutorial, API labels alone do not set.

Amazon's getBillOfLading reference describes the call as returning "PDF document data for printing a bill of lading for an Amazon-partnered Less Than Truckload/Full Truckload (LTL/FTL) inbound shipment." In the partnered carrier tutorial, it appears as a step marked "[Only for Pallet Shipments]." A small parcel shipment, or a pallet shipment on your own carrier, does not use it. How the BOL works as evidence once the freight moves is in our guide to BOL, POD and the FBA paper trail.

Tracking flows the other way. With a non-partnered carrier, "you must share the tracking ID using the updateShipmentTrackingDetails operation." For LTL, that means a PRO number (also called the freight bill number), with the BOL number optional. For small parcel, it means an array of box IDs and their tracking IDs. Amazon makes that update a requirement for non-partnered carriers, and in either case there is no step to mark the shipment as shipped: "Amazon automatically tracks the shipments based on the carrier and tracking details."

Workflow Two: Pack Later, for Pallets Only

The second diagram applies when carton contents are not known when the plan is created. Amazon limits it to pallets. The Pack Later guide says the workflow "is available for both Amazon Partnered Carriers or Your Own Carriers but only for Pallet Deliveries," and the FAQ says that without carton information "you can only create a Less Than Truckload/Full Truckload (LTL/FTL) shipment."

The order flips. Placement is confirmed first, and box contents come after:

• Plan and placement. createInboundPlan, generatePlacementOptions, listPlacementOptions, then confirmPlacementOption. Only one placement option can be confirmed per plan.
• Box contents. setPackingInformation, sent against the shipment ID instead of the packing group ID. Amazon's rule: with carton-level information known, pass the PackingGroupId and omit the ShipmentId; otherwise include the ShipmentId and omit the PackingGroupId.
• Freight. generateTransportationOptions with the pallet quantity, dimensions, weight and stackability and the freight information (declared value and freight class), then listTransportationOptions and the FREIGHT_LTL option, partnered or your own carrier.
• Delivery window, own carrier only. generateDeliveryWindowOptions, listDeliveryWindowOptions and confirmDeliveryWindowOptions, for every shipment in the plan.
• Confirm and print. confirmTransportationOptions, getShipment for the shipmentConfirmationId, then v0 getLabels with the number of pallets.
• Tracking, own carrier only. updateShipmentTrackingDetails with the freight bill number.

The practical point for operations is that Pack Later commits the destinations before the carton contents reach Amazon. In Amazon's documented order, transportation options are generated only after placement is confirmed, so the destination is fixed before the freight quote exists.

Build or Buy: What Operations and IT Are Signing Up For

Amazon publishes a Fulfillment Inbound sample solution on GitHub, with a Pack Later variant, so the question is rarely whether a team can write the calls. The question is what it takes to run them every day without a person watching. From the documentation alone, a build has to handle these:

• Asynchronous state. Every POST returns an operationId, and nothing moves until getInboundOperationStatus says so.
• Two shipment IDs and two versions. Labels take the shipmentConfirmationId, and they come from v0.
• Expiring options. Placement and transportation options expire, and delivery window options carry a validUntil date.
• Locks and money. Placement cannot be reversed, and partnered freight becomes a charge after the void window.
• Prep setup and the Send to Amazon boundary. setPrepDetails per MSKU, options discarded if someone switches to Send to Amazon too early, and no ready_to_ship from API labels.

"Manual operations are becoming extinct."

Bernardo Campelo, in a Forbes Business Council article, January 9, 2026

None of these is hard on its own. Together they are a state machine with money attached, and the cost of a build sits in the edge cases: the plan recreated after a count changes, the window that expired over a weekend, the label pulled with the wrong ID. A team that ships a few plans a month can live with Send to Amazon and a careful operator. A team that ships every day, across many SKUs, is the one the state machine pays back.

"Once the workflow is automated, the logic is the same: the machine doesn’t get tired."

Bernardo Campelo, in a Forbes Business Council article, January 9, 2026

Buying has its own questions. If a 3PL or a software vendor says it "integrates with Amazon," ask which of the calls above it runs on your authorization, which it leaves to a person, and what happens to a plan when its connection breaks halfway. Our post on native integration versus middleware lays out the three things "we integrate" can mean and the questions that separate them. What the software should show operations and finance once the shipment is moving is in what prep center software should show.

Where a Prep Center Fits

A prep center sits on the physical side of every step above. In the US, Amazon no longer preps or labels for FBA, so the prep owner and label owner in the plan describe real work that someone has to do before the boxes close. The carton count that goes into setPackingInformation is only as good as the count at the packing station, and the pallet details that drive LTL options come from the dock. A prep center can also be the ship-from address in the plan.

What a prep center does not control is Amazon's side: the placement Amazon offers, its fees and discounts, the partnered freight rate, the delivery weeks Amazon opens, and the receiving at the fulfillment center. Any provider that promises a specific placement or rate is promising something Amazon decides.

PrepVia is an Amazon SP-API authorized partner with its own integration. On the shipments we build, it covers inbound plan creation, placement options, box content, partnered freight booking and receiving status, as listed on our company facts page. The prep and labeling behind those calls happen in our Miami warehouse at 8507 NW 72nd St, Miami, FL 33166, with a prep window of 24-36 hours, and we ship with Amazon partnered LTL and FTL. The rest of what the app does is on the PrepVia app page.

Frequently Asked Questions

Is the Fulfillment Inbound API v0 deprecated?

Partly. The v0 operations that created plans and shipments, such as createInboundShipmentPlan, createInboundShipment and putTransportDetails, were removed on January 21, 2025. Six v0 operations were not deprecated, and two of them, getLabels and getBillOfLading, are still necessary to create shipments.

What is the order of calls to create an FBA inbound shipment with v2024-03-20?

With carton contents known: createInboundPlan, packing options, setPackingInformation, placement options, transportation and delivery window options, the confirmations, v0 getLabels (plus getBillOfLading for partnered pallets), and tracking for non-partnered carriers. In the Pack Later workflow, for pallets only, placement is confirmed before box contents are sent.

Where does setPrepDetails go in the workflow?

Before the plan. Amazon says sellers set it once per MSKU in each store, it is saved for future shipments, and the prep category it sets can affect which prep and label owners createInboundPlan accepts. Prep details entered in Seller Central are not returned by listPrepDetails.

Do I need getBillOfLading for every shipment?

No. Amazon describes getBillOfLading as returning a bill of lading for an Amazon-partnered LTL or FTL shipment. Small parcel shipments and pallet shipments on your own carrier do not use it.

Can I send a small parcel shipment without knowing what is in each box?

Not through the Pack Later workflow. Amazon limits that workflow to pallet deliveries (LTL/FTL). For small parcel, box information goes in through setPackingInformation before placement. Without the contents, the source is MANUAL_PROCESS, which Amazon charges a fee for, and box dimensions and weight are still required.

How long do I have to cancel partnered freight after confirming it?

Amazon allows a void within 24 hours of confirmation for small parcel and within one hour for LTL or FTL. After that, the account is charged for the shipping cost. In v2024-03-20, the call is cancelInboundPlan, which cancels the whole inbound plan.

Final Take

Sending to Amazon by API in 2026 means two versions and two workflows. v2024-03-20 builds the plan, and v0 still prints the labels and the partnered pallet bill of lading. With carton contents known, boxes come before placement; with Pack Later, which is for pallets only, placement comes first. Prep details are set per SKU before any of it, and two confirmations, placement and partnered freight, cannot be taken back cheaply.

The build-or-buy decision comes down to who owns that state machine on a busy day. Map each call to a person or a system before the 2027 plan is written, and ask any provider the same question about each call.