Amazon FBM Orders Reports: What to Request and Why

Use Seller Central FBM Order Reports for fulfillment data, and use the Amazon Selling Partner API (SP-API) MCP to request SP-API All Orders reports when the job is tracking, support, reconciliation, or a finance period cut. Those are different files with different risk profiles, even though operators often call both "FBM orders."

The practical question came from an ops lead: "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?" The answer is yes for the support file, not by that name for the warehouse file. Amazon Agent Atlas retrieved the Seller Central FBM Order Reports article and Amazon's SP-API order report type values reference, and the distinction matters: one is a fulfillment file with buyer data; the other is an order-tracking report family that Amazon explicitly says is not for driving seller fulfillment.

A plain ChatGPT or Claude client hits the same three walls on this job. It has no access to your data, so it cannot see your seller account, marketplaces, or last successful report window. It has no way to take action, so it cannot call createReport, poll getReport, or retrieve the report document. And it runs on generic knowledge, not Amazon's, so it easily collapses Seller Central FBM reports, restricted fulfillment reports, and SP-API All Orders tracking reports into one imaginary endpoint. The MCP brings account access and report tools; Atlas brings the exact Amazon rule corpus; Skills make the request, polling, download, and archival loop repeatable.

Start with the fulfillment question, not the API endpoint

Amazon's Seller Central FBM Order Reports article says the FBM order report is a tab-delimited text file for seller-fulfilled products sold during a selected period. It includes the buyer information needed to fulfill orders, but not confidential billing or credit-card information. It can be generated manually for the past 1, 2, 7, 15, or 30 days, and it can be scheduled. Because Seller Central does not generate those reports beyond 30 days, the operational pattern is simple: archive the daily file if it is your warehouse record.

The SP-API All Orders report family answers a different question. In Amazon's order report type values reference, Amazon describes the All Orders reports as order-tracking reports available in all regions and for all sellers. They return all orders regardless of fulfillment channel or shipment status, but they are intended for tracking, not fulfillment, because they do not include customer-identifying information and scheduling is not supported.

For a warehouse, that distinction is not academic. A warehouse dispatch queue needs shipment-ready buyer data. A support or operations queue often needs "what changed since yesterday" and can safely operate from order ID, SKU, status, channel, quantities, city/state/postal/country, and prices. The agent should branch on that intent before it asks the SP-API MCP for anything.

Request all-orders by last update when operations need changed orders

When support asks "what changed since the last sync," the MCP should request GET_FLAT_FILE_ALL_ORDERS_DATA_BY_LAST_UPDATE_GENERAL. Amazon's reference says this report contains all orders updated in the specified period, covers MFN and FBA, is available to sellers, and returns a tab-delimited flat file. It is a requested report, not a scheduled one, and the date range is limited to 30 days. For self-fulfilled pending orders, Amazon also notes that item price is not shown, so do not use this report as a pending-order revenue ledger.

This is the right operational feed for support queues, warehouse exception review, cancellations, shipment-status changes, and downstream systems that reconcile on last-updated-date. It also avoids a common off-by-one mistake: if a customer changes or cancels an older order today, an order-date report for today's placed orders will miss it, but a last-updated report will catch it.

{
  "mcp": "amazon-spapi",
  "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"
  }
}

The agent should store the successful window boundary with the run log, then make the next request from the prior dataEndTime. That is a Skill responsibility, not something an operator should remember in a prompt.

Request all-orders by order date 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. The same SP-API order type values reference says this report 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 order extracts, reconciliation against BI tables, and date-based audits.

For FBM-only analysis, do not request a different report just because the business says "FBM." Request the All Orders period cut, then filter the rows where the fulfillment channel is merchant fulfilled. The report's value is that it holds both MFN and FBA orders, so the same extract can support FBM exception analysis and whole-account reporting.

{
  "mcp": "amazon-spapi",
  "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"
  }
}

If the request is a historical backfill by order date, Amazon's archived order report reference identifies GET_FLAT_FILE_ARCHIVED_ORDERS_DATA_BY_ORDER_DATE as the archived-orders report type. Keep that as a deliberate backfill path, not the default daily workflow.

Let the SP-API MCP handle polling, retrieval, and storage discipline

Atlas also pulled Amazon's Reports API tutorials for requesting a report, verifying report processing, and retrieving a report document. The sequence is mechanical, which is exactly why it belongs in a Skill.

1. Call createReport with reportType, marketplaceIds, and optional dataStartTime / dataEndTime.
2. Poll getReport with the returned reportId until processingStatus is DONE, CANCELLED, or FATAL.
3. If DONE includes reportDocumentId, call getReportDocument.
4. Download the returned pre-signed url before it expires, applying compressionAlgorithm if present.
5. Keep encryption at rest; Amazon's retrieve tutorial warns against storing unencrypted report content on disk, even temporarily.

{
  "mcp": "amazon-spapi",
  "tool": "reports.getReport",
  "arguments": {
    "reportId": "amzn1.spapi-report.example"
  }
}

{
  "mcp": "amazon-spapi",
  "tool": "reports.getReportDocument",
  "arguments": {
    "reportDocumentId": "amzn1.spdoc.example"
  }
}

The failure states matter. CANCELLED can mean Amazon found no eligible data. FATAL can still include a document that explains the failure. IN_QUEUE and IN_PROGRESS are not terminal, so the agent should keep polling instead of telling the operator the report is missing.

What happens next

In production, the Amazon Ads MCP, the Selling Partner MCP, Skills, and the Amazon Agent Data layer sit behind one agent surface, so a support request can pull the right SP-API order report, archive it, and hand downstream teams the same audited artifact. The same pattern powers the approval loop in Preview Listing Patches Before They Go Live: retrieve the governed source, perform the narrow action, write the run log, and keep the operator out of manual repeat work.

For this guide, the narrow action is report selection. A warehouse dispatch workflow needs the Seller Central FBM fulfillment file or a restricted fulfillment path. A support, finance, or reconciliation workflow should ask the SP-API MCP for the All Orders report type that matches the date logic.

Next in the series: using SP-API order status changes to decide when an agent should notify support, warehouse operations, or finance without turning every report row into an alert.

{"mcp":"amazon-spapi","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-spapi","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-spapi","tool":"reports.getReportDocument","arguments":{"reportDocumentId":"amzn1.spdoc.example"}}