Product feed management: questions people actually ask

With Feedwyre, minutes, not weeks - import a spreadsheet, connect a database, or point at an FTP file, generate an API key, and you're querying real data. There's no mapping project or implementation timeline the way EDI or a full PIM rollout requires.

At minimum a unique product code, name, price, and stock level. Everything else - category, brand, images, custom attributes - is optional and adds value as you have it. Feedwyre lets you define exactly which fields are searchable, which are required, and which come back in a response, rather than forcing one fixed schema.

Use a Sandbox-environment API key so test calls are clearly separated from live traffic in your usage logs, and try the built-in API tester right in the dashboard before writing any client code. Import a handful of real products first and check the responses look right before pointing a live integration at it.

It depends what you're actually solving. A Google Shopping or ad-catalog problem needs a different tool than a "give my resellers live stock" problem. If EDI, a full PIM, and a plain marketplace ad-feed tool all feel like overkill or the wrong shape, that's usually the sign you need something API-first and reseller-focused instead - see what a product feed API actually is.

It ranges enormously - full PIMs like Akeneo run $45K+ a year, EDI vendors like SPS Commerce start around $99/mo and scale with partners, and marketplace ad-feed tools run roughly $64-239/mo metered by SKU count. Feedwyre starts with a free 7-day trial and paid plans from $39/mo, with no per-SKU metering.

If your data already lives in a spreadsheet, scheduled CSV/Excel import is the lowest-effort option - no database credentials, no server setup. If it's already in a database or gets written to a file automatically, database sync or scheduled FTP/SFTP import removes the manual step entirely. See our database sync vs. CSV import vs. scheduled import guide for the tradeoffs.

Manual means someone re-uploads a file whenever they remember to. Automated means a schedule, or a live database or file connection, does it without anyone remembering anything.

As often as the underlying data actually changes and matters to whoever's reading it - stock and price often warrant real-time or hourly updates, while descriptions and images can lag. A live Query API reads current data with no caching delay regardless of how often the source syncs.

A bulk-update API call can update price and stock for many products in one request without resending everything else about each one. Since every channel reads the same live feed, one bulk update is visible everywhere at once - there's no separate export per channel to re-run.

Start narrow: which fields can be searched, which are required, and which come back in a response. For pricing rules specifically, a child feed with its own margin rule applies automatically on every read, so there's no separate rule engine to maintain.

For most B2B buyers, three fields decide whether they trust the feed at all: accurate stock, accurate price, and a stable product code they can match against their own system. Everything else - images, descriptions, custom attributes - matters for usability, but those three are what actually block or unblock an order.

If Shopify is your only channel and you manage it directly in Shopify's own admin, probably not. If Shopify is one of several channels reading from the same underlying catalog, a shared feed keeps all of them in sync from one source instead of you updating Shopify and everything else separately.

Yes - create one feed per store, or one parent feed with a child feed per store if they should share the same underlying catalog at different prices. Each store gets its own API keys, independently scoped and revocable, without maintaining separate copies of the data.

It's the general idea of one catalog reaching several destinations - your storefront, a marketplace, a reseller's system - without maintaining a separate export for each. See building a multi-channel product feed for how that works from one live source.

Most e-commerce platforms manage their own product catalog, but few give an external partner a real-time, authenticated API into it - that's usually a separate layer, especially if you need to serve resellers or partners the platform wasn't built for.

Before the switching cost grows - the longer partners are integrated against your current setup, the more coordination a change takes. A natural trigger point is when you're about to onboard a new reseller or channel anyway, since that's integration work you'd be doing regardless.

A feed health check run on demand flags out-of-stock products, missing prices or images, stale products, duplicate barcodes, and low stock if you've set a threshold, with the exact products to fix, not just a count. An activity log separately shows every change in plain language, so you can see what happened and when.

It depends on the failure - a bad scheduled import or sync run shows up in that tab's log with the specific error, a rejected booking returns an honest "insufficient stock" response instead of silently overselling, and a health check surfaces data-quality problems before a partner hits them. Nothing silently deletes products; a sync that returns fewer rows than expected just leaves the rest untouched.

Run a feed health check - it flags every barcode shared by more than one product so you can see exactly which ones collide. From there it's usually a data-entry fix on whichever product has the wrong code.

A single feed health check that surfaces out-of-stock items, missing prices or images, stale data, duplicate barcodes, and low stock all at once beats hunting through the catalog by hand. Run it periodically, not just when something's already gone wrong.

A download link gives you the current catalog as CSV, XLSX, or JSON on request, generated fresh from live data rather than a stale scheduled export. Links are scoped and independently revocable, so a backup export doesn't have to share credentials with anything else reading the feed.

Start with the response code - a 429 means you've hit your plan's rate limit (wait for the Retry-After header, it's not billed as a used call), a 401 or 403 usually means a missing or revoked key. See our rate limits guide for the specifics.

If exactly one system reads your catalog and it's fine with data that's a day old, a plain export is simpler and a feed API is unnecessary complexity. It earns its keep once more than one system needs the same data, or stock actually runs out sometimes and two systems can disagree about it.

Yes, for large parts of it - spreadsheet import, a dashboard product editor, and a self-service ordering portal need no code. Generating and calling an API key does need a developer on whichever end is building against it.

Because manually emailing spreadsheets or taking phone orders doesn't scale past a handful of accounts, and once a competitor can answer "is this in stock" instantly instead of "let me check," that becomes the expectation buyers carry into every conversation.

Mostly by removing re-keying - an order that arrives already correct (right price, right stock, right product code) never needed the phone-call-then-retype cycle a manual process costs. See the true cost of manual order entry for the fuller breakdown.

That it doesn't have to mean an EDI project or a PIM implementation. For most distributors the actual blocker is giving resellers live stock and a way to order, which a feed API solves directly, without the mapping expertise or six-figure rollout either of those bigger tools assumes you need.