Unable to retrieve Tracking ID for MFN orders

[Quankzx]

Hello everyone,

I’m currently facing an issue retrieving the tracking ID for MFN (Merchant Fulfilled Network) orders.

From my understanding, most APIs only allow fetching new order data, but do not seem to provide a way to reliably retrieve or backtrack the tracking ID once it’s missing.

Has anyone encountered this issue before or found a feasible workaround or API approach to handle MFN tracking IDs?

Any insights or suggestions would be greatly appreciated. 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: 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

[chrisskhoury]

Hello! I have some good news :)

The Orders API v2026-01-01 is now officially launched, and we've added comprehensive package tracking information specifically for FBM orders based on feedback like yours!

You can now retrieve tracking IDs, carrier information, and package status directly through the new packages[] array. Simply use the getOrder or searchOrders endpoints with includedData=PACKAGES:

GET /orders/2026-01-01/orders/{orderId}?includedData=PACKAGES

This works for both new orders and historical orders, so you can backfill any missing tracking data.

Check out the official documentation for complete details and examples:

• Orders API v2026-01-01 Announcement - Official launch announcement and release notes
• Orders API Reference - Complete API specification with endpoints, parameters, and schemas
• Orders API Migration Guide - Comprehensive step-by-step migration documentation
• Orders API Use Case Guides - Implementation patterns for common scenarios
• Migrate to Orders API v2026-01-01: Interactive Developer Guide
• Postman Collection: Orders API Migration Collection (Interactive hands-on migration guide)Use Case Guides - Real-world examples

Questions?
📧 orders-api-feedback@amazon.com or 💬 GitHub Discussions

This should solve your tracking ID challenge! Let us know how it goes. 🚀

Best,

Chris Khoury
Solution Architect - Amazon SP-API

[Quankzx]

Thank you for sharing the information. The new API is truly great as it resolves the issue of retrieving the tracking code for MFN orders. However, I noticed that the tracking code for AFN orders does not seem to be returned in the searchOrder and getOrder APIs (version 2026-01-01), even though I have included includedData=BUYER,RECIPIENT,FULFILLMENT,PACKAGES. It appears that the packages information is only returned for MFN orders. I look forward to your response

[chrisskhoury]

Hello @Quankzx

The Package details that are returned with the New Orders API are for FBM Orders only.

For FBA, we do have the getPackageTrackingDetails endpoint that should help you for the outbound shipments.

Hope this answers your question?

Best,
Chris Khoury
Solution Architect - Amazon SP-API

[AnsonHwang86]

Hello, in V0, we don't need apply the restricted token, we can get {"BuyerInfo":{"BuyerEmail":"xxxx@marketplace.amazon.com"} }. this is property is used so widely as buyer ID. it was a Virtual email addresses should not be considered as guests' private information. So even don't apply restricted Token, we can get that value as in V0, thanks.

[chrisskhoury]

Hello @AnsonHwang86 !

Thanks for bringing this up. I am curious to better understand the use case here: are you primarily using the virtual email for buyer identification/deduplication, or are there other workflows where you use this field? Understanding the specific use case will help us provide the most relevant guidance.

Best,
Chris Khoury
Solution Architect - Amazon SP-API

[Quankzx]

Hello @chrisskhoury

For shipments using Amazon Buy Shipping (MFN), to retrieve tracking events for order journey:

Is it mandatory to use both CarrierId and TrackingId in Shipping v2 getTracking, or is there a way to use only TrackingId?
If we retrieve the latest order data (Orders API v2026-01-01) and it includes a TrackingId but no CarrierId/CarrierCode, how can we retrieve the full tracking history/events?

I'm building journey tracking and need confirmation to handle this case.