Amazon FBM Order Reports vs the All Orders Report

To fulfill Fulfilled by Merchant (FBM) orders, use Seller Central's FBM Order Report or the restricted SP-API report GET_FLAT_FILE_ORDER_REPORT_DATA_SHIPPING, which carry buyer shipping data. For tracking, support, reconciliation, or a finance period cut, have the Amazon Selling Partner API (SP-API) MCP request an All Orders report, which carries no customer-identifying information.

A typical version of the question: "We need a daily FBM order file for the warehouse and a support file for changed orders. Can the agent just pull the FBM report through SP-API?" Yes for the support file. Yes for the warehouse file too, with a condition: the SP-API version is a restricted report, and the connection needs Amazon's restricted shipping role to open it.

ChatGPT, Claude, Perplexity, Microsoft Copilot, and whatever comes next know nothing about your business out of the box. Kuudo gives those same tools your data, your rules, and the way your business operates. The Selling Partner MCP requests and retrieves the reports, Amazon Agent Atlas supplies Amazon's report rules, and your workspace approval policy decides whether a report request waits for you.

Start with the fulfillment question: Atlas separates the dispatch file from the tracking file

Atlas retrieved Amazon's Seller Central FBM Order Reports article and the SP-API order report type values reference. Together they sort the reports into two jobs: files that carry buyer shipping data, and files built for tracking.

The fulfillment files

• Seller Central FBM Order Report. A tab-delimited file of seller-fulfilled orders received in the days you select, including cancelled and shipped ones. It includes the buyer information needed to fulfill orders, but not billing address or credit-card information. Professional and Amazon Business sellers only.
• Manual or scheduled. Generate it for the past 1, 2, 7, 15, or 30 days, or schedule it. A scheduled report holds only new orders since the last one, and by default runs every 24 hours after 11:00 p.m. Pacific time.
• SP-API equivalents. GET_FLAT_FILE_ORDER_REPORT_DATA_SHIPPING holds MFN orders from the previous 60 days and can be requested or scheduled. GET_FLAT_FILE_ACTIONABLE_ORDER_DATA_SHIPPING holds only orders not confirmed as shipped.

Seller Central does not generate its FBM report beyond 30 days, and Amazon recommends archiving the daily reports. If that file is your warehouse record, archive it.

The tracking files

Amazon describes the All Orders reports as order-tracking reports, available in all regions and for all sellers. They return every order regardless of fulfillment channel or shipment status. Amazon says they are intended for tracking, not to drive a seller's fulfillment process, because they do not include customer-identifying information and scheduling is not supported.

They do carry order ID, SKU, ASIN, order and item status, fulfillment channel, quantity, prices, and ship city, state, postal code and country. That is enough for a support or exception queue. It is not a shipping label.

Pull the warehouse file through the Selling Partner MCP only with the restricted role and an RDT

GET_FLAT_FILE_ORDER_REPORT_DATA_SHIPPING is the SP-API route to the dispatch file. Amazon marks it restricted because it contains customer personally identifiable information (PII). Three conditions apply:

1. The role. The SP-API application needs the Direct to Consumer Shipping (Restricted) role, which requires passing an additional security review.
2. The token. When calling getReportDocument for a restricted report type, you must pass a Restricted Data Token (RDT). The Selling Partner MCP exposes Tokens_createRestrictedDataToken to request one.
3. One schedule. A seller can schedule only one GET_ORDER_REPORT_DATA_SHIPPING or GET_FLAT_FILE_ORDER_REPORT_DATA_SHIPPING report at a time. Scheduling a new one cancels the existing schedule.

Confirm your connection holds the restricted role before routing the warehouse file this way. Without it, keep the Seller Central FBM Order Report as the dispatch file and use the MCP for the tracking reports below.

Request All Orders by last update through the Selling Partner MCP when operations need changed orders

When support asks "what changed since the last sync," request GET_FLAT_FILE_ALL_ORDERS_DATA_BY_LAST_UPDATE_GENERAL. Amazon's reference says it contains all orders updated in the specified period, covers MFN and FBA, and returns a tab-delimited flat file. It can only be requested, and the date range is limited to 30 days.

For self-fulfilled orders in a pending state, Amazon notes that item price is not shown. Do not use this report as a pending-order revenue ledger.

It is the right feed for support queues, warehouse exception review, cancellations, shipment-status changes, and systems that reconcile on last-updated-date. An older order that is cancelled or ships today appears in today's last-updated report. An order-date report for today's placed orders misses it.

{
  "mcp": "Amazon Selling Partner MCP",
  "tool": "Reports_createReport",
  "arguments": {
    "reportType": "GET_FLAT_FILE_ALL_ORDERS_DATA_BY_LAST_UPDATE_GENERAL",
    "marketplaceIds": ["ATVPDKIKX0DER"],
    "dataStartTime": "2026-06-21T00:00:00Z",
    "dataEndTime": "2026-06-22T00:00:00Z"
  }
}

Start each run where the last completed one ended. Reports_getReports filters by report type and processing status, and each report it returns carries its dataStartTime and dataEndTime. No published Kuudo Skill covers order reports, so save this windowing rule as your team's own Skill rather than retyping it in a prompt.

Request All Orders by order date through the Selling Partner MCP when finance needs a period cut

When finance or planning asks "what orders were placed in this period," request GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL. It contains all orders placed in the specified period, with MFN and FBA rows in a tab-delimited file. Use it for daily sales cuts, month-to-date extracts, reconciliation against BI tables, and date-based audits.

For FBM-only analysis, request the same period cut and filter on the fulfillment-channel column afterward. Because the report holds both MFN and FBA orders, one extract serves FBM exception analysis and whole-account reporting.

{
  "mcp": "Amazon Selling Partner MCP",
  "tool": "Reports_createReport",
  "arguments": {
    "reportType": "GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL",
    "marketplaceIds": ["ATVPDKIKX0DER"],
    "dataStartTime": "2026-06-01T00:00:00Z",
    "dataEndTime": "2026-06-22T00:00:00Z"
  }
}

For a historical backfill by order date, Amazon's reference lists GET_FLAT_FILE_ARCHIVED_ORDERS_DATA_BY_ORDER_DATE, which contains all archived orders placed in the specified period. Keep it as a deliberate backfill path, not the default daily workflow.

Let the Selling Partner MCP poll, retrieve, and store the report under your approval policy

Atlas also pulled Amazon's Reports API tutorials for requesting a report, verifying processing, and retrieving a report document. The sequence is mechanical, which is why it belongs to the agent rather than to an operator.

1. Call Reports_createReport with reportType, marketplaceIds, and optional dataStartTime / dataEndTime. It is a write tool, so it runs under your workspace approval policy.
2. Poll Reports_getReport with the returned reportId until processingStatus is DONE, CANCELLED, or FATAL.
3. When DONE returns a reportDocumentId, call Reports_getReportDocument, with an RDT for a restricted report type.
4. Download the pre-signed url within five minutes, when it expires, and decompress when compressionAlgorithm is present.
5. Keep encryption at rest. Amazon's retrieve tutorial says unencrypted report content must never be stored on disk, even temporarily.

{
  "mcp": "Amazon Selling Partner MCP",
  "tool": "Reports_getReport",
  "arguments": {
    "reportId": "amzn1.spapi-report.example"
  }
}

{
  "mcp": "Amazon Selling Partner MCP",
  "tool": "Reports_getReportDocument",
  "arguments": {
    "reportDocumentId": "amzn1.spdoc.example"
  }
}

The terminal states matter. CANCELLED means someone cancelled the request before processing, or Amazon found no data to return. FATAL might include a reportDocumentId whose document explains why processing stopped. IN_QUEUE and IN_PROGRESS are not terminal, so the agent keeps polling instead of telling the operator the report is missing.

What happens next: match each order workflow to its report

In production, the Selling Partner MCP, the Amazon Ads MCP, your team's Skills, and the Amazon Agent Data Layer sit behind one agent surface. A support request pulls the right SP-API order report, and Agent Flow lands Selling Partner and Amazon Ads data in a lake you own, so downstream teams read the same copy. Preview Listing Patches Before They Go Live applies the same approval pattern to listing writes.

For this guide, the narrow action is report selection. A warehouse dispatch workflow needs the Seller Central FBM Order Report, or the restricted SP-API shipping report when the connection holds the role. A support, finance, or reconciliation workflow asks the Selling Partner MCP for the All Orders report that matches its date logic.

Next in the series: the common pitfalls of reading orders from the SP-API Orders API, one order at a time.

{"mcp":"Amazon Selling Partner MCP","tool":"Reports_createReport","arguments":{"reportType":"GET_FLAT_FILE_ALL_ORDERS_DATA_BY_LAST_UPDATE_GENERAL","marketplaceIds":["ATVPDKIKX0DER"],"dataStartTime":"2026-06-21T00:00:00Z","dataEndTime":"2026-06-22T00:00:00Z"}}

{"mcp":"Amazon Selling Partner MCP","tool":"Reports_createReport","arguments":{"reportType":"GET_FLAT_FILE_ALL_ORDERS_DATA_BY_ORDER_DATE_GENERAL","marketplaceIds":["ATVPDKIKX0DER"],"dataStartTime":"2026-06-01T00:00:00Z","dataEndTime":"2026-06-22T00:00:00Z"}}

{"mcp":"Amazon Selling Partner MCP","tool":"Reports_getReportDocument","arguments":{"reportDocumentId":"amzn1.spdoc.example"}}