Listing and inventory updates

Auto updating listings is possible on 51 of the 221 platforms in this section. This page groups those by the mechanism they use, because the mechanism decides the latency, the batch size and, most importantly, how you learn that a write failed.

The other 170 divide into carriers, where the concept does not apply, vendor purchase order models where the platform owns the catalogue, and platforms with no programmatic write path at all.

Read this with the unified data model for the listings and inventory tables, and Webhooks and rate limits for the schedule.

Where writes are possible

Single item synchronous call

The write returns success or a field level error in the HTTP response. This is the easiest mechanism to build against and the easiest to rate limit yourself out of.

Shopify (productVariantsBulkUpdate, inventorySetQuantities), BigCommerce, WooCommerce, Magento, Wix, Etsy, eBay, Shopee (update_stock, update_price), Lazada (price_quantity/update), Daraz, Trendyol (price-and-inventory), Wish, Temu, TikTok Shop, noon, Snapdeal, Myntra, ShopClues, Flipkart (listings v3), StoreHippo, Shopaccino, Shoptimize, Commerce7, GoFynd, Pepperfry, Shopify POS, Udaan, LBB, and the Shopify backed stores My Baby Babbles, NatureFit and OneGuardian.

Practical notes drawn from the platform pages:

• Shopify caps input arrays at 250 items across the API, while a single product may hold up to 2048 variants. The variant ceiling is not the batch ceiling.
• Etsy allows 10 requests per second and 10,000 per day. A full catalogue resync of more than 10,000 listings cannot complete in one day.
• Shopee and Lazada sign every request, so a batch is many signed calls, not one.
• Flipkart, Snapdeal and Myntra accept price and stock in the same call, which halves the request count if you always send both.

Feed or bulk job with a processing report

You submit a document, receive a job identifier, and poll for a report. The report is the only place per item errors appear: the submission itself almost always succeeds.

Amazon (JSON_LISTINGS_FEED through Feeds 2021-06-30), Walmart (feeds and feed status), Best Buy (Mirakl OF24 JSON and CSV offer imports), Magento (bulk and asynchronous API), Shopify (bulkOperationRunMutation for large batches), Salesforce Commerce, SAP, Oracle and Microsoft Dynamics (data management framework).

Batch sizes and timings worth knowing: Amazon feed processing is typically minutes but has no guaranteed completion time and degrades during peak retail periods. Walmart feed status must be polled; there is no push. Mirakl accepts both a JSON offer import and CSV templates, and reports per line errors in an import report.

Partner or enterprise only

The capability exists but credentials require a commercial conversation, so it cannot be built speculatively.

NetSuite, Salesforce Commerce (price books), Tata 1mg, Logic ERP, Focus 9 and QueueBuster.

Panel bulk upload template only

A human downloads a template, fills it and uploads it. No API exists. These are worth listing explicitly because they are often mistaken for integrable channels: Limeroad, BigBasket, FirstCry, Meesho catalogue changes, and AJIO.

Where writes are genuinely impossible

Three distinct reasons, and they need different responses from the business.

1. Carriers. 99 pages in this section are carriers or logistics tools. They have no catalogue. The write path is creating and cancelling a shipment, which is documented on each page under the same heading.
2. Vendor purchase order models. The platform owns the catalogue and the retail price, and buys stock from you. Pushing a price is not merely unsupported, it is meaningless. FirstCry, BigBasket, Blinkit, Zepto, Swiggy Instamart, DealShare, PharmEasy and Elastic Run. Price changes here are negotiated with a buying team.
3. No platform. Roughly twenty catalogue entries could not be confirmed as live products. Those are listed on the overview with low confidence and each page says what was checked.

A recommended update pipeline

The design below is what the 51 writable platforms have in common. It assumes many channels per SKU and assumes every channel will fail independently.

1. A stock ledger as the source of truth

One append only ledger of stock movements per SKU per location. Current availability is a derived view, never a stored number that processes mutate. Every movement carries a reason: sale, return, receipt, adjustment, reservation, release.

This matters because the alternative, a mutable quantity column updated by several consumers, produces oversells that cannot be explained after the fact. With a ledger, any disputed quantity can be replayed.

2. A per channel outbound queue

One queue per channel + channel_account_id. Never one global queue: a slow channel must not delay a fast one, and a channel in an error state must be pausable on its own.

Each queued item is a desired end state, not a delta: "SKU X on channel Y should be price P and stock Q". If three updates for the same SKU and channel are pending, collapse them to the last one before sending. This is the single largest reduction in call volume available, and it is what keeps a catalogue of any size inside Etsy's 10,000 calls per day.

3. Idempotency keys

Key each write on channel + channel_account_id + channel_listing_id + the target state hash. If a response is lost to a timeout, the retry carries the same key and can be recognised as a duplicate rather than applied twice.

Few of these platforms offer a server side idempotency key, so in most cases this is a client side guard: check the key before sending, and record the outcome against it after. It prevents the common failure where a timeout is retried, both calls land, and a price is applied twice with a promotion in between.

4. Reconciliation read after write

Never trust a 200 response as proof the catalogue changed.

• For synchronous platforms, re-read the listing after a short delay and compare against the desired state. Discrepancies go back on the queue.
• For feed platforms, poll the processing report and parse per item errors. A feed that is accepted and then rejects 400 of 500 lines is the normal failure, not an exception.
• Run a full reconciliation sweep per channel on a slow cycle, daily is usually enough, comparing listings.stock (the channel's belief) against the ledger's derived availability. The gap between those two numbers is the health metric for the whole pipeline.

5. Failure modes to design for explicitly

• Silent partial success. The commonest failure on feed platforms. Detected only by reading the report.
• Stale belief after a channel side edit. A seller edits a price in the panel and your listings row is wrong until the next read. Webhooks cover this on some platforms; on the rest only the reconciliation sweep will catch it.
• Blocked or pending listings. A listing can be rejected for catalogue quality reasons and accept stock updates while remaining unbuyable. Track listings.status, not just price and stock.
• Clock skew on signed platforms. Shopee, Lazada, Temu, TikTok Shop and the other signing platforms reject requests whose timestamp drifts. A signature failure is a clock problem first and a credential problem second.
• Oversell during a promotion. The window between a sale and the stock push is where oversells happen. Reserve on order creation in the ledger, not on dispatch.

6. What to alert on

Alert on the reconciliation gap and on queue age, not on individual call failures. Individual failures are constant and self healing. A channel whose queue age exceeds its normal sync interval, or whose reconciliation gap grows for more than one cycle, is genuinely broken and needs a human.