Przejdź do treści
Case study: from zero to €1.5M in monthly Amazon sales See how we did it →
Amazonway

Product data

Amazon flat file: the report says success but nothing changed

Szymon Żynda · Seedlight · · approx. 9 min read

An Amazon processing report confirms that your file was accepted and processed. It does not confirm that the change reached the catalogue. Those are two different things, and Amazon says so in its own documentation: the DONE status only means processing has finished, and a whole separate class of problems appears after a submission is accepted, outside the report entirely. That is why fighting with a file is blind work. You upload another version, you wait, you get the same confirmation, and you still do not know what went wrong. Below: what the processing statuses actually mean, how to diagnose a case like this before you send a tenth file, and when it pays to move to SP-API, with an honest list of what that costs you.

Amazon documentation as of 13 August 2026. This piece is based on the official Selling Partner API documentation (Feeds, Listings Items, Product Type Definitions), and the two cases described here come from our own work and are labelled as experience, not as a documented rule. Amazon updates status names, attribute names and rate limits, so confirm them in the current version of the docs and in your own account before you build anything on them.

What "success" in a processing report actually means

A flat file, meaning a bulk submission of listing data, goes through a queue. Amazon reports its state as a processing status, and that is the first place where it is easy to misread what you are looking at. Those statuses describe what happened to the file, not what happened to your listings.

StatusWhat it meansWhat follows from it
IN_QUEUEThe file is waiting and has not started processingProduct data feeds are processed sequentially, so a new one waits for earlier ones to finish
IN_PROGRESSProcessing is under wayProcessing time does not depend on record count: a file with a handful of rows can still take hours
DONEProcessing has finishedThis is not a confirmation of success. Amazon tells you to examine the contents of the report to find out whether there were errors
FATALProcessing was aborted by a fatal errorSome, none or all of the operations in the file may have gone through. Catalogue state has to be checked separately
CANCELLEDThe submission was cancelled before processing beganNothing happened, and there is no report content to analyse

Source: Amazon SP-API, Submit a feed. The same page notes that under high load it is not uncommon for feeds to take up to eight hours to process.

The second layer matters more and is less obvious. Even once a submission is accepted, the story is not over. In its guidance on managing listing issues, Amazon states that "accepted" does not mean the process is complete: several downstream processes create the item in the catalogue, and any of them can raise an issue that comes back asynchronously, long after you received your confirmation.

That is where the effect comes from that looks like an outage but is ordinary system behaviour: report closed, zero errors, zero changes in the account. The same mechanism applies to price and stock updates, so a silent failure in a bulk submission during FBA inventory management simply means you are selling units you do not have, or not selling the ones sitting in the warehouse.

Two cases from our own work

The two stories below are our experience, not a rule from the documentation. We describe them because they show the real cost of diagnosing a problem through files alone.

Variations that would not attach

With the first client, child variations could not be attached to the parent product. We would send the flat file, Amazon would return a success confirmation, and 48 hours later it turned out the change was not there. No error message, no indication of a cause.

We contacted Amazon support roughly six times about the same issue and never received an answer that explained it. In parallel we ran the standard routine: another version of the file, one detail changed each time, because there was no way to tell which one was the culprit. Every attempt meant more waiting.

To this day we do not know what exactly Amazon was rejecting. We have no error code from those uploads, because the report did not return one and support did not supply one either. What we do know is that once we switched to API calls, the case closed the same day.

Products that could not be created at all

The second case was harsher: the products could not be added at all. Again a success confirmation, again nothing in the account, again many attempts with hours of waiting between them.

In both cases we closed the matter in a single day by working through SP-API (the Selling Partner API) instead of sending more files blind. We wrote and ran the calls in Claude Code, which shortened the path to the first working request. The tool itself fixed nothing: what fixed it was the feedback the file never gave us. It is a good example of a job where AI genuinely helps a seller, because it works against a verifiable system response rather than against copy written on instinct.

An honest caveat: "one day" describes our two cases, not a promise. Catalogue size, product type, marketplace and whether you already hold developer access all move that number in either direction.

Why the API shows what the file will not

The difference is not that the API is somehow more powerful. In its FAQ for the listings APIs, Amazon states plainly that the feed enqueues your bulk submission and then invokes the Listings Items API on your behalf. Both routes end up in the same place. The difference is what you see, and when.

RouteWhen feedback arrivesWhat the response is attached to
File uploaded in Seller CentralAfter processing finishes, so anywhere from minutes to hoursThe submission. Messages refer to rows in the file, not to the state of a listing
Feeds API (JSON_LISTINGS_FEED)Asynchronously, once processing completes; you can subscribe to the FEED_PROCESSING_FINISHED notificationThe feed submission, with a list of issues that blocked acceptance and a separate list of issues raised after acceptance
Listings Items APISynchronously, in the response to a single requestOne specific SKU: submission status, submission ID and a list of issues

That last row is the whole point. The response from putListingsItem or patchListingsItem carries a submission status (ACCEPTED, INVALID, VALID) and a list of issues, each with a code, a message, a severity (ERROR, WARNING, INFO) and the names of the attributes involved. Instead of "something is wrong with your file" you get the name of a field.

Three more things come with it that file work simply does not offer:

  • Error preview without persistence. A request with mode=VALIDATION_PREVIEW validates a listings item without persisting the data in the catalogue. You can test a fix before anything touches the live account.
  • Listing state on demand. The getListingsItem operation with includedData=issues shows the issues attached to that listing right now, including the ones that surfaced after your submission was accepted.
  • Requirements instead of guesswork. The Product Type Definitions API returns a JSON schema describing attribute requirements for a product type in a given marketplace. It answers "which field is mandatory here" before you fill in a template.

One change is also worth knowing, because it passed many sellers by: since 31 July 2025 the Feeds API no longer supports legacy XML and flat file listings feeds covering listings, pricing, inventory, relationships and images. Amazon is explicit that this does not affect files submitted by sellers directly through Seller Central. The panel still works; an integration built on the legacy feed types does not.

A procedure: what to check before you send another file

Order matters here, because each step rules out a different family of causes. For each one we note what you do in the panel and what you do through the API.

  • Step 1. Check the listing, not the submission report. The report describes a file; the listing record describes a product. Through the API: getListingsItem with includedData=issues. In the panel: the issues view on that specific SKU.
  • Step 2. Establish whether the file finished at all. Anything other than a terminal status (DONE, FATAL, CANCELLED) means there is nothing to judge yet. Submissions run sequentially, so an earlier upload can hold up the next one.
  • Step 3. Pull the product type requirements for that marketplace. The schema from the Product Type Definitions API settles which attributes are mandatory. The same product type can carry different requirements in different countries.
  • Step 4. Narrow the change to one SKU and one attribute. A bulk submission blends causes together. A single request returns an answer attached to a single listing.
  • Step 5. Use the validation preview instead of an upload. Preview mode returns the list of issues without writing anything, which cuts the feedback loop from hours to seconds.
  • Step 6. Check whether something else is overwriting your data. Amazon does not guarantee that submissions are processed in the order they appear in a feed, and data from other sources can take priority over yours. Two integrations running in parallel are perfectly capable of undoing each other.
  • Step 7. Only now open a support case. A case containing an issue code, an attribute name and a submission ID is a conversation about something specific. A case saying "I uploaded a file and nothing happened" usually comes back asking you to upload the file again.

A rule of thumb from our practice: if after two full cycles (file, report, no change) you still have no error code, a third file will not give you more information. It will only give you more waiting.

Variations: where this quietly breaks

Parent-child relationships are the most fragile part of listing data, because a single valid listing is not enough. The relationship between listings has to line up as well. Amazon expects three things from a child listing at once:

  • Position in the family: the parentage_level attribute set to child.
  • A pointer to the parent: the child_parent_sku_relationship attribute, with a relationship type of variation and the parent product's SKU.
  • The variation theme: variation_theme matching the theme set on the parent, together with the attributes that theme requires.

The last point is the easiest one to trip over. Choosing a variation theme, size and colour for instance, obliges you to populate the corresponding fields on every child listing. A missing value on one child can sink the whole operation, and in a spreadsheet it looks like one empty cell among hundreds.

Was that the cause at our client? We do not know, and we are not going to pretend otherwise. The case closed through the API before we established what exactly the file route was rejecting. Unsatisfying, but true.

When to move to the API, and what it costs

Moving to the API is not free and it does not pay off for everyone. Before you consider it, price in four costs of entry.

  • Developer access. You need a registered SP-API application and authorisation on the seller account, with roles appropriate for listings management. It is a formality, but it takes time.
  • Skills. Someone has to be able to send an authenticated request and read a JSON response. A coding assistant shortens the path to the first working call; the decision about what goes to a live account still belongs to a person.
  • Rate limits. On a large catalogue this is a real constraint, not paperwork. The createFeed operation is limited to 0.0083 requests per second with a burst of 15, and for the JSON_LISTINGS_FEED type Amazon adds a cap of 5 submissions per account every 5 minutes and 25,000 records per submission. Listings Items operations run at 5 requests per second per account-application pair, and the validation preview mode carries its own, stricter limit. The documentation quotes different values for that mode in different places, so check the current rate limits page before you design an integration.
  • Maintenance. Product type schemas change. An integration nobody watches will, within months, start sending data that no longer matches the current requirements.

So when does it add up? When the problem is repeatable, meaning the same operation fails across many SKUs; when the catalogue is large; when the price of one failed attempt is measured in hours; or when you need to compare the state of a listing against what you believe you sent. For a one-off fix across twenty listings, the file is still faster and there is nothing embarrassing about using it.

It is also worth separating two problems: a data error and a process error. If the same fields come back as non-compliant month after month, the cause sits further upstream, in the source of the data and the way it is distributed. Automating that layer, meaning validating listings against channel rules before publication, is what our sister brand Seedlight does as part of its listing error analysis service.

What the API will not fix

Moving to requests changes the quality of the feedback you get, not the physics of the platform. Several things stay with you.

  • Asynchronous issues do not disappear. An ACCEPTED status still means "accepted for processing", not "finished". Verifying the listing with a separate call remains part of the process.
  • Order is still not guaranteed. Submissions within a feed are not necessarily processed in the order they appear in it.
  • Not every missing change is a data error. Some blocks come from policies, category rules or product compliance, and they show up somewhere other than an API response. If a listing disappears or refuses to go active, check your Account Health page as well.
  • Support can still be the bottleneck. An error code transforms the conversation, but some cases cannot be closed from the seller's side at all.

How Amazonway works on this

When we run client accounts, we treat listing data as technical work rather than as clicking through templates. The order is always the same: establish the state of the listing and the issue code first, then choose the tool. The file is one of the tools, not the starting point. That scope sits inside marketplace account management, while the fundamentals of creating and optimising a listing are covered in our guide chapter on listing a product.

An honest caveat: not every case can be resolved from our side, and we do not promise repair deadlines, because part of the decision sits inside Amazon systems we have no visibility into. What we are accountable for is that the diagnosis rests on an issue code and the actual state of the listing, rather than on one more version of a file sent on a hunch.

FAQ: flat files, processing reports and the API

Why does my flat file report success when the products are not there?

Because the report describes the processing of a submission, not the state of the catalogue. The DONE status means "processing complete", and Amazon tells you to examine the report contents for errors. On top of that, some problems only arise after a submission is accepted, inside the processes that create the item in the catalogue, and they come back asynchronously. So the listing has to be checked separately.

How long does Amazon need to process a file?

There is no single number. The documentation notes that under high load processing can take up to eight hours, and that report generation time does not depend on the number of records: a file with a few rows can still take hours. Product data feeds are processed sequentially.

Will moving to SP-API solve every listing problem?

No. It changes the quality of the feedback: you get an issue code, its severity and the attribute names involved, all attached to a specific SKU. Asynchronous issues, the lack of a processing-order guarantee and blocks driven by policy or category rules all remain.

Can I test a fix before it touches the live account?

Yes. The putListingsItem and patchListingsItem operations with the mode=VALIDATION_PREVIEW parameter validate a listings item without persisting data in the catalogue. That mode has its own rate limit, so it is not suited to scanning an entire catalogue in a short window.

Has Amazon retired flat files?

Partly. Since 31 July 2025 the Feeds API no longer supports legacy XML and flat file listings feeds for listings, pricing, inventory, relationships and images. Amazon states that this does not affect files uploaded by sellers directly in Seller Central, so working in the panel is still possible. Integrations built on the legacy feed types had to move to JSON_LISTINGS_FEED or to the Listings Items API.

What should a support case contain to get a useful answer?

From our practice: the SKU, the marketplace, the submission or feed ID, the issue code together with the attribute name, and a description of what you expected versus what you found. Without an issue code the conversation usually returns to square one, which is a request to upload the file again.

Sources

Stuck on listings that refuse to change?

If you are uploading another file and still have no error code, the problem is not the file. The problem is the missing feedback. We will work one specific SKU with you: what the listing state shows, what the submission returns, and whether this can be closed without rebuilding your integration.

Book a free technical consultation →