Reading the removals destination address from the Removal Order Detail Report endpoint

[tompavoi]

Is it possible to fetch de destination address from the removal orders report endpoint? So far the endpoint returns the same report that can be downloaded from the UI, which does not include the destination (Shipping to) field. I have already tried both reports: GET_FBA_FULFILLMENT_REMOVAL_ORDER_DETAIL_DATA and GET_FBA_FULFILLMENT_REMOVAL_SHIPMENT_DETAIL_DATA without success. This would be of great use so any suggestions or solutions will be greatly appreciated.

[onewholepiece]

Hi, just want to check if you were able to figure this out. Seems like this is still not available.

[puppsupr]

Hi,
The removal orders reports does not include destination address information. This information is only captured during the removal order creation process but is not included in the downloadable reports.
If you need to track where your removal orders were sent, you would need to:

• Keep your own records during the removal order creation process
• Reference individual removal orders in Seller Central (though this would be manual)

Can you please provide me your business use-case so that I can have a PFR request.

[onewholepiece]

Hello, we are fetching the removal order detail report via API to automate the creation of records in our ERP system. Getting the destination address information is important to us as we use that to differentiate which warehouse we should set when we create the transaction records.

[MetaMan2023]

@puppsupr

We have an exact need for this same request -- we need to access the shipping address that a removal was sent to. There are multiple reasons for this:

(A) We specifically need it because we put extra data into our manual removal requests that we need to access -- for example our address contains specific removal notes as a secondary line (ATTN: Removals - XXXXX) -- the XXXXX may contain specific internal codes that tell staff what to do with the inventory.

(B) It is useful for tracking fraud -- for example if an internal employee were to put in an inventory removal to a third party address (stealing inventory) we would be able to easily notice this in a report.

A few solution ideas:

#1: Allow the "getOrder" SP-API call to also pull data for removal orders. Amazon treats removal orders like regular orders in the Seller Central system, however the getOrder command only accepts the 3-7-7 format IDs. If getOrder (and additional commands like getOrderAddress I think? could also accept removal order IDs, this could partially solve the issue.

#2 : have the reports have additional fields that include the removal order destination address.

#3: offer another SP-API call specifically for details on removals -- maybe we can provide a removal order ID and get details of the removal.

#4: Alternatively, allow us to put a specific note SEPARATE from the shipping address when creating a removal order such as "WAREHOUSE PROCESSING NOTE" -- in a perfect world this would be printed on the box and also noted in the removal order report in a column. Another idea you could allow us to put data that could be encoded into a barcode for a note, so instead of a visually readable note, we could put our own internal tracking id for a removal (lets say "JOHNS_REMOVAL_12345" and you would encode that into a 2D barcode. You could have a limit on # of characters. That would be printed on the box and our warehouse could scan it to use internally to track.

Regardless -- at a bare minimum some way to get the return address is really necessary.

It is extremely complicated to process removals -- and the few methods we have (such as putting special notes in the address) are very limited due to these options missing.

[MetaMan2023]

@puppsupr

Just to add a note -- we handle over 30,000 removals a year due to our business size. Manually typing in codes read off a box are not practical. We can receive a pallet of boxes a day, so scanning them is necessary.

[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: oig@ftc.gov

• 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: lyxdirect@163.com