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", which is exactly how fawcett's notes describe the file. 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 — Trellis sends 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. Trellis used to send dataStartTime and dataEndTime both set to today — a zero-width window, which is not what "the last day of feedback" asks for — along with ShowSalesChannel, which is an order-report option and does nothing here. Both were removed.
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 — which is what fawcett's note describes too, 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. fawcett's notes describe the file as 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 how fawcett's notes describe the file too. 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.