SP-API: Handling 'Prep and Labeling Details' for Existing Offers

[JesusR25]

Hello everyone,

I am creating offers for existing catalogs, and I have managed to do this successfully as mentioned. However, when I go to the Amazon platform and try to add stock, I get the following message:

"Prep and labeling details needed."

Is there any endpoint or resource in the SP-API that allows me to provide this information? Also, is there a way to retrieve this data for offers that already have it?

[MetaMan2023]

I am not familiar with what you mean by "creating offers for existing catalogs" however that error you noted sounds like you need to use:

listPrepDetails
setPrepDetails

List will tell you what current prep details are and Set will let you set them. This is for FBA Inbounding, the new API version 2024-03 requires this done for all SKUs at least once.

[puppsupr]

Hi @JesusR25,
All the SKUs should have prep and label details. Please see below for more details,

Call the listPrepDetails operation to retrieve preparation instructions for shipping an MSKU into Amazon’s fulfillment network in a specific marketplace. You can use listPrepDetails to determine which prepOwner and labelOwner values can be used in the createInboundPlan operation. Appropriate prepOwner values are returned in prepOwnerConstraint and appropriate labelOwner values are returned in labelOwnersConstraint. If these fields are empty in the response, you can select AMAZON or SELLER. If allOwnersConstraint is MUST_MATCH, prepOwner and labelOwner must match. If allOwnerConstraint is empty, then prepOwner and labelOwner do not need to match. You can also use this operation to retrieve the current prepCategory and prepTypes for an MSKU (if they are already set), which indicates how each MSKU must be prepared. If prepCategory is FC_PROVIDED, then Amazon has established a prepCategory for this MSKU and it cannot be changed.

Call the setPrepDetails operation to provide information related to how an MSKU is prepared for shipment. Sellers must provide this information once for each MSKU in a marketplace. Amazon saves this information for future shipments that include this MSKU. 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. Use the listPrepDetails operation to retrieve the available prep and label owners. If PrepType is ITEM_NO_PREP, you may still need to include a prep owner or label owner when you call createInboundPlan. If prepCategory is NONE, you might need to include a label owner in createInboundPlan. In both situations, you can identify the list of available prep and label owners with the listPrepDetails operation.

When you call setPrepDetails, you must pass the prepCategory and prepTypes for each MSKU and marketplace ID. For more information about the relationship between prep category and prep types, refer to Prep guidance.

Here is the link for FBA inventory requirements.

[restructor1]

Thanks

[SylvieManx]

I'm Manx, a third-party developer with many years of experience working within the Amazon ecosystem. I'm writing this email today to join you in speaking out against Amazon's newly introduced unreasonable pricing policy for its SP-API and to defend the survival of us small and medium-sized developers!

Since 2009, SP-API and its predecessor, MWS, have been freely available. This openness has fostered a thriving developer ecosystem. The ERP, inventory management, and data analytics tools we've developed have become indispensable operational support for millions of Amazon sellers. However, without consulting any developers, Amazon suddenly announced a fixed subscription fee of $1400 per year starting January 31, 2026, with an additional monthly fee based on GET requests starting April 30. This unilateral and mandatory charging completely disregards the legitimate rights of developers!

I. Three Core Injustices in the Pricing Policy, Targeting the Lifeline of Small and Medium-Sized Developers

1. The High Fixed Annual Fee: The $1400 annual subscription fee applies regardless of size or profitability. Even small and medium-sized developers serving only a few sellers and barely breaking even must bear this enormous fixed cost. Many features have very low profit margins, and this fee puts us in a desperate situation of "no service, no pay" or "losses."

2. Severe Disconnect Between Pricing and Service Quality: Amazon's API service has long suffered from stability issues. Many colleagues have encountered problems such as official demo errors, multiple failed permission requests, and call anomalies. Even more frustrating is that when we open a case for consultation, we often don't receive a valid response for one or two weeks. This combination of "low-quality service + high fees" completely violates the principles of fair business practices.

3. Forced Bundling Under a Monopolistic Position: SP-API is the only legal channel for connecting to Amazon's platform data; we have no alternatives. Amazon, leveraging its market dominance, forces all developers reliant on its ecosystem to accept unreasonable fees, essentially engaging in monopolistic practices that exclude market competition and squeeze developers' profits.

II. Collective action is the only way out: File a joint complaint with the FTC, demanding Amazon rectify its practices. Individual voices are easily ignored, but our combined strength is enough to drive change! The U.S. Federal Trade Commission (FTC) specifically tracks unfair business practices, and its Consumer Sentinel Network aggregates and analyzes all complaints to form a basis for regulatory action. Here, I urge every affected developer to immediately submit a complaint through the following official channels:

• Complaint Email: [email protected]

• Online Complaint Form (most convenient): reportfraud.ftc.gov

• Mailing Address: Federal Trade Commission, Consumer Sentinel Network, Washington, D.C. 20580

• Complaint Hotline: 1-877-438-4338 (English service) When filing a complaint, please emphasize the following core issues: Amazon's abuse of its SP-API monopoly to suddenly introduce unreasonable fees; the $1400 fixed annual fee squeezing the survival space of small and medium-sized developers; a serious mismatch between service quality and fees; and the lack of prior consultation and a transition period.

III. Our Demands: Reject Monopolistic Exploitation, Demand a Reasonable Fee Mechanism
We are not against reasonable fees, but rather we resist a "one-size-fits-all" monopolistic fee model. We strongly urge Amazon to:

1. Suspend the current pricing policy and publicly negotiate a new pricing plan with the global developer community;

2. Introduce a tiered pricing mechanism, offering low-threshold entry-level packages or fee reductions for small and medium-sized developers;

3. Improve service quality, ensure API stability, and clarify technical support response times (e.g., responding to cases within 24 hours);

4. Publicly disclose the basis for cost accounting, making pricing transparent and reasonable.

Dear colleagues, the prosperity of Amazon's ecosystem depends on the contributions and innovation of every developer. This current "discarding the millstone after it has served its purpose" pricing policy will not only force many small and medium-sized developers out of the market, but will also ultimately lead to fewer sellers, increased operating costs, and disrupt the balance of the entire ecosystem.

Please take immediate action and forward this email to more developer partners to jointly file a complaint with the FTC! Every complaint is a contribution; only by uniting can we make Amazon take our demands seriously and safeguard our legitimate rights!

We look forward to witnessing the arrival of fairness and justice together! Initiator: Manx
Contact Email: [email protected]