Multi-marketplace listing management automation, by API

Multi-marketplace listing management automation means one agent holds the master record for each product and pushes price, stock, title and photo changes to every storefront through that storefront’s own API. It handles the rate limits, retries what fails, reads each listing back to confirm the change landed, and flags anything a person must decide. It does not take orders or touch payment.

We run a tool like this for our own seller accounts. This post covers the job, what the agent does step by step, what changed, and what the same build costs as a Sprint. Figures about marketplaces come from their published developer docs, read in October 2026.

The job: one product, several storefronts, one source of truth

A product sold on three storefronts exists in three places, and each copy drifts. Someone changes a price in one dashboard, stock sells down on another, a photo gets rejected on a third, and nobody finds out until a customer does.

The failure that costs real money is stock. A listing that shows stock you no longer have produces a cancelled order. Walmart’s Marketplace developer documentation (2026) tells sellers to keep their cancellation rate within a stated standard, and the sample response in its cancellation summary endpoint shows that standard as “below 2%”, measured over a 14, 30, 60 or 90 day window you choose. One stale stock count is cheap. A habit of them is a standing problem with your seller account.

That is the job we gave an agent: keep every listing matching the master record, and say so when it cannot.

Why each marketplace needs its own handling

Every marketplace API has different limits, so one generic “push to all” script breaks within a week. The agent needs a per-marketplace rulebook for how fast it may write and how it should back off.

The published numbers show how different they are:

Marketplace API	Published limit (docs read October 2026)	What it means for a sync
Amazon Selling Partner API, Listings Items (v2021-08-01)	5 requests a second per seller-and-application pair, burst of 5; product-data updates capped at 100 requests a second per application	A big catalogue update has to be queued and paced
Shopify GraphQL Admin API	100 points a second on Standard, 200 on Advanced, 1,000 on Plus; no single query above 1,000 points	Cost depends on what the query asks for, not how many calls you make
Walmart Marketplace	Cancellation rate standard “below 2%” in the performance endpoint’s sample	The penalty for bad stock sync shows up in seller standing, not in an error code

Sources: Amazon Selling Partner API developer documentation, Shopify developer documentation, Walmart Marketplace developer documentation.

Two different ideas of a limit sit in that table. Amazon counts requests. Shopify counts the cost of what you ask for, using a leaky bucket that refills continuously, so short bursts are fine if the average stays under the restore rate. An agent that treats both as “N calls a minute” will either crawl or get throttled.

The third row is the quiet one. Nothing errors. The cost of a bad sync arrives weeks later as a metric.

What the listing agent does, step by step

The work is done by a tomte, our word for one production agent with one defined job. Ours has a narrow remit: find the difference between the master record and each storefront, fix what is safe to fix, and report the rest.

1. It reads every listing on a schedule. A daily pass looks at each listing on each connected storefront and records what is online, what is offline, what was rejected, which titles are too short and which listings are missing photos. This pass is read-only.
2. It sorts the findings into a fix list. Problems are grouped by product group so a person reviewing sees “eleven listings with a missing photo”, not eleven separate alerts.
3. It writes changes through the marketplace’s own API. Price, stock and description edits go out paced to that marketplace’s published limit, with a retry and a longer wait when it is throttled.
4. It keeps credentials alive. Marketplace access tokens expire. A daily job refreshes them, so a sync does not fail at 3 a.m. because a token lapsed on Tuesday.
5. It holds new listings back. One marketplace we use goes live automatically when a new listing is approved, even if the seller meant it to stay offline during review. A guard job runs every ten minutes and takes any listing made through the dashboard back offline unless someone pressed Publish on purpose. That rule exists because of a mistake we would rather you did not repeat.
6. It reports every run. Each run writes a result to the same run log the rest of our agents use, so a missed run is visible without anyone opening a dashboard.

The scope is deliberate. The agent finds, quotes and reports on listings and shipping details for orders that already exist. It never places an order and never handles payment on either side. A person decides prices that move margins and anything the agent flags as unusual.

What changed

Three things changed once the agent took over the sync.

First, listing problems stopped being found by customers. The daily read surfaces rejected listings and missing photos before a buyer meets them.

Second, expired access stopped being a surprise. Token refresh runs as its own job, with its own result in the run log.

Third, accidental go-lives stopped. The ten-minute guard means “created” and “published” are two separate decisions again.

We are not publishing a time-saved figure for this agent. We have not measured one we would defend, and a made-up percentage would break our own rule that every claim carries a source or a date.

Where it stops

Honest limits, as of October 2026:

• It manages the listings, not the strategy. Which products to list, and at what margin, stays with a person.
• Each new marketplace is new work. The signing method, token flow and field names differ. Adding a storefront means a new rulebook, not a setting.
• The read-back only proves what the marketplace shows. If a storefront’s API reports success while its search page lags, the agent sees success. We spot-check the public page, which is a person’s job.
• Order handling is a different build. For that side, see how order processing is automated end to end.

What this costs to set up

A listing-management agent for your storefronts is one AI Workforce Sprint: from $9,500 fixed, four to six weeks, built on your seller accounts and your hosting, then handed over with documentation and a recorded walkthrough. A typical order is one marketplace and the read-only daily audit in the first weeks, then paced writes and the guard job once the audit has run clean. Change is a new order, not a surprise invoice. You own the delivered code, data and documentation.

The listing agent runs inside the same governance layer as our other agents: an owner, a scope and a kill switch per agent. Our agent fleet case study shows that layer, with 41 agents registered and 5,450 runs at zero failures over 13 days measured to July 2026.

Start async

If your listings live in several dashboards and you suspect they disagree, start async. Tell us in writing which storefronts you sell on and how stock is tracked today, and we reply within one business day. No calls.