As soon as you're selling in more than one place — even just your own inventory system plus one marketplace — you have a feed: a structured, repeating transfer of product, price, and inventory data from wherever it's authoritative on your end to wherever it needs to show up. Understanding how a feed actually flows, and where it commonly breaks, matters more the more channels and systems you add.

What a feed actually is

A feed is not a single event — it's a defined data structure (which fields, in what format) sent on some cadence (real-time, hourly, daily) from a source system to a destination system. The most common feed types sellers deal with are:

  • Catalog/content feed — product titles, descriptions, images, attributes; usually updated less frequently since content changes less often than price or inventory.
  • Inventory feed — stock-on-hand counts; needs to update frequently enough that a marketplace doesn't show "in stock" for something you've actually sold out of.
  • Price feed — current selling price, sometimes including promotional pricing; update frequency needs vary based on how often you reprice.
  • Order feed — flows the opposite direction, from the marketplace back to your systems, carrying new orders that need to be fulfilled.

Where a feed's "source of truth" lives

For any given piece of data, exactly one system should be authoritative — the place where a value is genuinely correct and every other system's copy of that value is downstream of it. For most sellers, inventory counts are authoritative in a warehouse/inventory management system (or an ERP), not in any individual marketplace's dashboard; pricing may be authoritative in a separate pricing tool or a spreadsheet, depending on how sophisticated your repricing process is. A common structural mistake is editing a value directly in a marketplace dashboard that's supposed to be fed from elsewhere — the next scheduled feed sync will simply overwrite your manual edit with the "true" source value, and the manual change appears to mysteriously revert.

Why sync frequency matters

A feed that only syncs once a day means your marketplace listings can show stale inventory or price information for up to a full day after the real value changes. For a slow-moving, low-volume SKU this is often fine; for a fast-moving SKU close to selling out, an infrequent sync creates real risk of overselling (accepting an order for something you no longer actually have) or underselling (showing out-of-stock when you actually have inventory, losing sales for no reason). Match sync frequency to how fast the underlying data actually changes for that specific SKU or feed type, rather than using one blanket frequency for everything.

How a feed typically flows through your systems

A common structure for a seller running multiple marketplaces:

Inventory/PIM system (source of truth) → Middleware/integration layer → Individual marketplace APIs/flat file uploads

The middleware layer (sometimes a dedicated multichannel listing tool, sometimes a custom integration) handles translating your internal data structure into each marketplace's specific expected format — this is where a lot of feed-related errors actually originate, since each marketplace's expected field names, controlled attribute values, and file structure differ even for conceptually identical data.

Common feed problems

  • Sync delay causing stale data — the most common and most visible feed problem, usually showing up as an inventory or price mismatch between your internal system and what's live on a marketplace.
  • Field mapping errors — an internal field mapped incorrectly to a marketplace's expected field, silently sending wrong data even when the feed itself "succeeds" with no error.
  • Partial feed failures — similar to a bulk upload's row-level failures (see Bulk Uploads and Flat Files), where most of a feed processes correctly but a subset of records silently fail.
  • Conflicting sources of truth — two systems both trying to be authoritative for the same field, causing values to flip back and forth unpredictably as each system's sync overwrites the other's.

Best practices

  • Explicitly define, in writing, which system is the source of truth for each data type (inventory, price, content) rather than leaving it implicit.
  • Set sync frequency per data type based on actual volatility — inventory and price generally need tighter sync than descriptive content.
  • Monitor feed success/failure status actively rather than only noticing a problem once a listing is visibly wrong.
  • Never manually edit a value in a downstream system (a marketplace dashboard) that's supposed to be fed from an upstream source — fix it at the source instead.

FAQs

  • Do I need dedicated feed management software, or can I get by with manual updates? A small catalog on one or two marketplaces can often get by with manual or semi-manual updates; once you're managing enough SKUs across enough channels that manual updates can't keep pace with actual inventory/price changes, dedicated middleware becomes worth the cost — see How Marketplace Integrations Work.
  • What's the difference between a feed and a bulk upload? A bulk upload is typically a manual, one-time file submission; a feed is an ongoing, usually automated, repeating data flow. The underlying data structure concerns (exact field matching, controlled values) are similar for both.