Use Cases

The orders that shouldn’t have existed

How an AI agent with direct Selling Partner API access found a fault that Amazon’s own reports, Seller Central, and three rounds of Seller Support could not.

The problem

An Amazon UK seller — FBA only, no warehouse, no despatch operation — kept receiving merchant-fulfilled orders. Orders they were expected to pack and post themselves, for a business that has never posted anything.

Each one had to be cancelled. Cancellations damage account health. Over twelve months there were 259 of them, across ten European marketplaces. The account had already been deactivated once. By August it was flagged “At risk” again.

The seller did everything right. They opened a support case. They checked their listings. They searched Seller Central for merchant-fulfilled offers.

Everything came back clean.

• Manage All Inventory, “Fulfilled by Merchant” filter: 0 results
• Amazon’s own listings report, every marketplace: 0 merchant offers
• Seller Support, three exchanges: “filter your inventory by Fulfilled by Merchant and convert or delete those listings” — for listings the filter did not show

Meanwhile, orders kept arriving. One marketplace reported zero merchant listings on a Tuesday and sold a merchant order on the Wednesday.

What the agent did

Connected directly to the Selling Partner API, it started where a human would — the reports — and got the same clean bill of health. So it went one layer deeper, and asked the Listings API for the listing’s raw submitted attributes rather than its live view.

There it was:

A second fulfilment entry — merchant channel, carrying 18 units of stock the seller never entered. Invisible to every report, because every report reads the live view, which shows only the Amazon entry.

A second API — Product Pricing — confirmed the offer was real and buyable: FulfillmentChannel: MERCHANT, £3.99. Two Amazon systems, describing the same SKU, at the same moment, disagreeing.

Then it proved the seller was powerless

The agent attempted both documented ways of removing a merchant fulfilment entry. Both returned HTTP 200, status: ACCEPTED, zero errors — and changed nothing. Re-read after two minutes, and again after seven: the phantom entry was still there.

That turned a support complaint into a defect report. Not “I can’t find the listing” — but “here are two submission IDs where your API accepted a deletion and deleted nothing.”

Then it measured the blast radius

Reports can’t see the fault, so there was no list to work from. The agent probed every listing individually — 1,077 in the UK, then all eleven European and Middle Eastern marketplaces. Around 7,400 checks.

Then it found the fact that reframed everything. An order placed that week had been routed to a phantom offer while Amazon held 12 fulfillable units of that exact SKU in its own warehouse. The phantom offer wasn’t a fallback for when stock ran out. It was outranking real inventory.

And it found the loop

An error message on an Italian listing, in Italian:

Round and round, for a year.

The outcome

1,327 phantom offers removed across two seller accounts and twelve marketplaces — 6,647 phantom units — with zero failures.

Every deletion was gated: dry run first, a live stock check against Amazon immediately before each removal, a restore log written before anything was touched. Listings holding stock were never deleted. When a session crashed 726 items into a 1,126-item run, the log made it resume exactly where it stopped.

What remains is the honest part: 35 listings still carry the fault. They hold 516 of the seller’s units, so they cannot be deleted, and Amazon’s API refuses to repair them. Those need Amazon — and the seller now has a four-page technical evidence pack proving it, including the submission IDs of Amazon’s own no-op deletions.

The case also produced the fastest fix nobody had thought of. The account’s own history showed Amazon had blocked merchant fulfilment at account level for roughly a year — which is exactly why the UK was quiet until they lifted it. Support had said no such setting existed. One switch, on their side, neutralises all 35 at once.

Why a normal tool couldn’t do this

Every dashboard, repricer and inventory tool reads the same reports the seller read. Those reports said the account was clean. A tool built on them would confidently report no problem — forever.

Finding this needed four things in combination:

• Direct API access, not a reporting layer — the fault only appears in a request parameter most integrations never send.
• Cross-checking systems against each other. The finding wasn’t in any single response. It was in the disagreement between the listings service, the pricing service, and the order stream.
• Willingness to test a hypothesis by writing — attempting the documented fixes and recording that they silently failed.
• Working at catalogue scale. 7,400 individual checks isn’t something a person does by hand, and it isn’t something a report will do for you.

Not one of those is exotic. They’re just not what tooling built around Amazon’s reports is shaped to do.

All figures are from a live production account, August 2026. Amazon case 13149942292.