What this report contains
One row is one piece of feedback a buyer left on your performance as a seller: the day they left it (date), the stars they gave (rating), what they wrote (comments), what you wrote back (your_response), the order it came from (order_id) and an email address for the rater (rater_email). Six columns, tab-delimited, and no more than that.
Two things follow from how short it is. First, it is about the transaction, not the product — seller feedback is Amazon's measure of your service, separate from product reviews, and nothing in the file names an ASIN or a SKU. order_id is the only route back to what was in the box.
Second, this is only the unhappy end of feedback. Amazon's report-type reference says the report "contains negative and neutral feedback (one to three stars) from buyers who rated the seller's performance", and that is the scope the production files carry. Read it as a complaints feed: a queue of things that went wrong, each one already attached to the order that caused it.
How to get it
Through the Selling Partner API, this is a Reports API job: call createReport with reportType: GET_SELLER_FEEDBACK_DATA, poll getReport until the processing status is done, then download the report document and read it as a tab-delimited file. That is the whole request: no reportOptions and no dataStartTime or dataEndTime, because per the report-type reference this report takes none.
That bare request is also the trap. Because you do not choose a window, Amazon returns whatever window it considers current, and a request that tries to narrow it gets it wrong in a way that looks like an empty report rather than an error. Setting dataStartTime and dataEndTime both to today is a zero-width window, which is not what "the last day of feedback" asks for, and ShowSalesChannel is an order-report option that does nothing here. Send neither.
The consequence for storage is worth planning for: every pull is a point-in-time snapshot rather than a slice of a period, so there is no requested range to file the download under. Each run lands a whole file dated by its ingest, and the feedback's own date lives in the date column. Partition on ingest and your day buckets will not mean what they say.
In Seller Central, the feedback itself lives under the Customers workspace: Amazon describes that workspace as where you find an overview of feedback ratings, with the Feedback Manager there to track buyer satisfaction and review recent feedback. Amazon publishes no console route that produces this file, so the API job above is how you get the file rather than the screen.
Sample rows
Illustrative values, not data from a real account. Shown to give the shape of the file.
| date | rating | comments | your_response | order_id | rater_email |
|---|---|---|---|---|---|
| 2026-09-18 | 1 | Box arrived crushed and the seal was already broken. | Sorry about that, a replacement shipped the same day. | 111-EXAMPLE-0000001 | [email protected] |
| 2026-09-18 | 3 | Product is fine but it turned up four days late. | 111-EXAMPLE-0000002 | [email protected] | |
| 2026-09-19 | 2 | Ordered the blue one and received the grey one. | Refunded in full, and the listing photo has been corrected. | 111-EXAMPLE-0000003 | [email protected] |
| 2026-09-20 | 1 | Never turned up. Tracking stopped at the depot. | We have opened a claim with the carrier. | 111-EXAMPLE-0000004 | [email protected] |
| 2026-09-20 | 3 | Works as described but the packaging was hard to open. | 111-EXAMPLE-0000005 | [email protected] |
Field reference
| Column | Type | Description |
|---|---|---|
date | date | The day the feedback itself was left, from the file's Date column. This is the only date in the report, and the one to place a row in time by — the file is not requested for a date range, so the run that downloaded it says nothing about the period it covers. |
rating | int64 | The star rating the buyer gave, as a whole number. Amazon scopes this report to negative and neutral feedback — one to three stars — so treat it as a complaints feed rather than as the input to an average rating. |
comments | string | The buyer's own comment, as free text in whatever language they wrote it. Empty where the buyer rated without writing anything. |
your_response | string | The public reply posted against this feedback, if there is one. Empty means nobody has answered it, which makes this column the working queue rather than a record. |
order_id | string | The Amazon order the feedback was left against. It is the join key to every order, shipment and return report, and the only way to find out what the buyer actually bought — the file carries no ASIN, SKU or product name. |
rater_email | string | An email address Amazon carries for the person who rated. Amazon's report-type reference lists the column and says nothing about its contents, and publishes no schema for this report type, so whether the value is a real buyer address or a marketplace-issued alias is not established. Personal data whichever form it takes, so it belongs behind the same controls as the rest of your buyer data. |
Use cases
Working the response queue. Rows where your_response is empty are the feedback nobody has answered yet. Sorted by date and rating, that is a work list you can hand to a support rota without anyone reading the console.
Finding the cause, not just the complaint. order_id joins straight to order and shipment reports, so a week of one- and two-star rows can be grouped by what shipped, when it shipped and how — which usually turns "our feedback got worse" into a specific SKU, carrier or fulfilment change.
Watching the shape of a bad week. Counting rows per date and per rating shows whether complaints are drifting up or arrived in a single spike. A spike almost always has one cause behind it; a drift rarely does.
Reading the comments as text. The comments column is the only place buyers describe the problem in their own words. Grouping recurring phrases — damaged packaging, late delivery, wrong variation — points at listing and packing fixes far faster than the rating alone does.
Keeping a record Amazon's console does not keep for you. Because each pull lands a whole file, storing them gives you a history of feedback text and your responses over time, which the file itself makes no promise to preserve.
Limitations and gotchas
It is not a date-range export. No dataStartTime, no dataEndTime, no options: you get the window Amazon considers current. Code that assumes a pull covers "yesterday" is asserting something the request never asked for.
Consecutive pulls overlap. Each run lands the whole current file, so loading two days of downloads into one table double-counts. De-duplicate on order_id and date before counting anything.
Never partition on the download date. The ingest date is a property of your job, not of the feedback. The date column is the feedback's own day, and it is the only one that means anything in a time series.
There is no product in this file. No ASIN, no SKU, no title. Any analysis by product needs the order_id join first, and orders with multiple items will not attribute cleanly to one of them.
Do not compute a feedback score from it. Amazon scopes the file to the negative and neutral end — one to three stars — so it is a numerator without its denominator. A rating average taken from these rows will be far worse than your real one.
rater_email is personal data, and you do not know which kind. Amazon lists the column and never says whether it carries a real buyer address or a marketplace-issued alias, so do not build anything — a mailing list least of all — on the assumption that it reaches the buyer. It arrives in a flat file that is easy to copy into a spreadsheet, which is exactly how buyer data escapes. Treat the column as restricted, and drop it from anything shared.
FAQ
No. Amazon's report-type reference states the report contains negative and neutral feedback — one to three stars — from buyers who rated your performance, and that is the scope the production files carry. Treat it as a complaints feed, and do not compute an average rating from it.
No. The report is requested bare, with no dataStartTime or dataEndTime and no report options, so Amazon returns whatever window it considers current. Setting a start equal to the end produces a zero-width window, not a single day.
It is the join key back to your order, shipment and return reports. The feedback file carries no ASIN, SKU or product name, so the order is the only way to learn what the buyer actually bought.
Because every run lands the whole current file rather than an incremental slice. Overlap is normal; de-duplicate on the order id and the feedback date before counting.
The date column in the file, which is the day the feedback was left. The date the file was downloaded describes your pipeline, not the data, and grouping by it will spread one day of feedback across several.
There is a rater email column, and the evidence establishes its name and type but not what Amazon puts in it. Either way it is personal data and should be handled as such.
Sources
Every researched claim on this page, and the Amazon or Walmart page it came from.
- fields.rating and the report scope — developer-docs.amazon.com/report-type-values-performance — the Flat File Feedback Report entry states the report 'Contains negative and neutral feedback (one to three stars) from buyers who rated the seller's performance.' The one-to-three-star scope is therefore Amazon's own statement rather than an inference, and it matches the production files.
- how-to-get-it — developer-docs.amazon.com/report-type-values-performance — the same entry gives 'Requested/scheduled: This report can only be requested' and 'Report output type: Tab-delimited flat file', and lists no reportOptions and no dataStartTime/dataEndTime parameters.
- fields — developer-docs.amazon.com/report-type-values-performance — the entry's attribute list is Date, Rating, Comments, Your Response, Order ID, Rater Email: the same six columns, in the same order, as the production files carry. Recorded as corroboration only; nothing on the column list changed.
- how-to-get-it (console) — sell.amazon.com/seller-central — 'The Customers workspace is where you can find an overview of feedback ratings and top search queries... use the Feedback Manager to track buyer satisfaction, and review recent feedback you have received from customers.' The page describes no download of this report file.
- seller_type — developer-docs.amazon.com/report-type-values — the Performance table lists GET_SELLER_FEEDBACK_DATA with Seller/Vendor availability 'Seller only', and the entry's own Availability line reads 'Sellers'.
- history_window — developer-docs.amazon.com/report-type-values — 'The retention of generated reports varies by report type. If an explicit retention is not specified for a report type, then the report will be retained for 90 days.' The Flat File Feedback Report entry specifies none, so the 90-day default applies to the generated document and says nothing about the data window.
- marketplaces — developer-docs.amazon.com/report-type-values-performance — the entry gives only 'Availability: Sellers' and no 'Amazon store availability' line, while developer-docs.amazon.com/report-type-values-fba carries explicit lines such as 'Amazon store availability: North America (NA)'. That the two lines are separate facts is visible in adjacent FBA entries: GET_AFN_INVENTORY_DATA_BY_COUNTRY carries 'Availability: Seller Central sellers' and 'Amazon store availability: Europe (EU)', while GET_AFN_INVENTORY_DATA directly above it carries 'Availability: FBA sellers' and no store line at all. An absent store line is therefore silence, not 'everywhere', so this field carries not-published: Amazon publishes no store list for this report.
- latency — developer-docs.amazon.com/report-type-values-performance — the Flat File Feedback Report entry states nothing about how often the data is refreshed, on a page where Amazon says so when it wants to: the Promotions Performance and Seller Coupons Performance entries both read 'Data for this report is updated on a daily basis', and FBA entries at developer-docs.amazon.com/report-type-values-fba read 'Content updated in near real-time'. No refresh interval is published for this report.
- cadence — developer-docs.amazon.com/report-type-values-performance — the entry gives 'Requested/scheduled: This report can only be requested' and lists no reportOptions and no dataStartTime/dataEndTime parameters, so no row set covers a period the caller asked for. The page carries snapshot on that basis: a download is a point in time, not a period.
- category — developer-docs.amazon.com/report-type-values — Amazon lists GET_SELLER_FEEDBACK_DATA under the 'Performance' category, and developer-docs.amazon.com/report-type-values-performance heads the section 'Performance Reports'. Nothing in the report is money, so the page carries account-health ('Seller feedback, performance notifications and policy metrics') rather than the scaffolded fees-and-finance.
- fields.rater_email — developer-docs.amazon.com/report-type-values-performance — the entry lists 'Rater Email' among the report attributes and says nothing whatever about what the column holds, and Amazon publishes no schema for this report type in its report schemas. Whether the value is a real buyer address or a marketplace-issued alias is therefore unknown, and the page says so rather than guessing. Amazon's 'anonymized email address of the buyer' wording for BuyerEmail at github.com/ordersV0.json describes a different API's field and is recorded here only to note that it was checked and is not evidence about this column.