Six catalogs, six ways to put one product feed to work.

One catalog, three storefronts.

Acme Outdoor Co. — a camping-gear brand selling direct, via a mobile app, and on a marketplace

Acme used to keep stock counts in three places: their website's CMS, a spreadsheet the marketplace team re-uploaded weekly, and whatever the mobile app last cached. The counts drifted apart. Popular items sometimes sold out on paper before they sold out in the warehouse, or the other way round, and a customer bought something that was already gone.

They moved their 900-item catalog into a single Feedwyre product feed and gave each channel its own API key against it. Every channel reads the same product data and books against the same stock count, so a sale on any one of them is immediately visible to the other two.

How it's set up

1. One feed holds all 900 products, imported once from Acme's existing spreadsheet.
2. The API config exposes sku and barcode as lookup fields, and category for group listings. That's the same shape every channel expects.
3. Three Query & Booking-scope API keys are generated, one per channel, each restricted to a channel-specific consumer code for cleaner order tracking. This scope can book a sale but can't edit the catalog itself, so a compromised storefront key still can't touch Acme's product data.
4. Each channel's checkout calls the booking endpoint whenever there's a sale. Feedwyre's atomic stock decrement means Acme doesn't need any extra locking logic of their own.

A fourth, read-only channel - say, a price-comparison partner who never books a sale - wouldn't even need a key. A secured download link scoped to just that partner serves the same shared catalog. It can be revoked on its own, without touching the three channels doing bookings.

A different price for every business you supply.

Northwind Wholesale — a distributor pricing the same catalog differently for each retail partner

Northwind's parent catalog runs to about 40,000 SKUs, comfortably inside Feedwyre's Scale plan, which is built for exactly this kind of distributor breadth. Northwind never sells at cost - every retail partner gets a markup, and it's rarely the same markup twice. Before Feedwyre, that meant a spreadsheet per partner, recalculated by hand every time a cost price changed, with no way to be sure a partner wasn't looking at stale numbers.

Now Northwind keeps real cost prices on one parent feed, and creates a child feed per partner with its own margin rules. Each child feed reads the parent's products live and applies that partner's markup before handing them back. Nothing is duplicated, and a cost-price change on the parent reaches every partner's feed automatically. Not every partner wants to integrate an API, either. Hardware Co's storefront calls a Query key live, while GreenLeaf Garden, a smaller shop with no developer on staff, just gets a secured download link they open in a spreadsheet every morning. Both are reading the same child-feed mechanism at the same enforced margin - only the delivery method differs. For a corner store that would rather not touch a spreadsheet or a key at all, Northwind sets them up with a consumer portal login instead. The owner signs in from their phone, sees their own child-feed prices, and books straight against Northwind's stock.

How it's set up

1. Northwind's real catalog lives on the parent feed, priced at cost. This feed is never handed out directly.
2. A child feed is created per partner, each pointed at the same parent.
3. Margin rules are set per child feed: a flat percentage or fixed amount by default, with per-category overrides where a partner's deal calls for one.
4. Hardware Co gets a Query key into their child feed for their own storefront to call. GreenLeaf Garden, who'd rather not integrate anything, gets a secured CSV download link into theirs instead: same child feed mechanism, same enforced margin, just no code on their end. A third partner with no developer and no interest in opening spreadsheets gets a consumer portal login on their own child feed, so they can browse and book from a phone or any browser. Every option is scoped to that one partner's child feed only - never the parent, and never each other's.
5. When Northwind updates a cost price on the parent, every child feed picks it up on its next sync and reapplies that partner's margin automatically. Hardware Co's next API call and GreenLeaf Garden's next CSV open both reflect it.

One catalog, a portal login for every business you supply.

Ridgeline Supply Co. — a wholesale distributor whose retail buyers order without any integration

Most of Ridgeline's retail buyers are small hardware and paint shops with no developer on staff and no interest in learning an API. For years the only options were a phone order, a faxed order sheet, or an EDI integration none of them could justify building. Whichever one a buyer picked, someone at Ridgeline still had to re-key the order into their own system by hand.

Now Ridgeline creates a consumer portal account within Feedwyre for every buyer, all reading the same shared catalog at the same list prices - there's no per-partner markup in this setup, just one catalog everyone orders from directly. Each buyer then signs into their own account, searches for what they need, and places the order themselves. It books against Ridgeline's real stock the same atomic way an API call would, so Ridgeline never promises inventory that's already gone.

How it's set up

1. Ridgeline's full catalog lives on one feed, priced the same for every buyer - there's no child feed or per-partner margin in this setup.
2. A consumer record is created per buyer business, using that buyer's own email address.
3. Ridgeline sets a password for that consumer's portal login and shares the portal link - no API key, no spreadsheet, nothing for the buyer to integrate.
4. The buyer signs in to Feedwyre, browses the catalog, and places orders directly. Every order books atomically against the same shared stock count as every other channel.
5. If a buyer eventually outgrows the portal - say they build their own ordering system - Ridgeline can issue them a Query & Booking key against the same feed without touching their portal login, or anyone else's.

One inventory list, a portal login for every branch.

Coastal Hardware Group — six branches booking against one shared stock count

Coastal Hardware Group runs six branches, and until recently each one kept its own rough stock tally - some on paper, some in a personal spreadsheet nobody else could see. Head office had no live view of what was actually on the shelves anywhere, and a branch that ran out of something would just phone around hoping another location had one spare.

Now head office manages one product feed for the whole company: adding items, adjusting stock, running a health check before a big delivery. Every branch gets its own consumer portal login into that same feed. A branch manager signs in to Feedwyre, sees the real shared stock count, and books what their branch needs. Two branches can never both claim the last unit of something, because every booking decrements the one real number atomically, the same way it would for an outside customer.

How it's set up

1. Head office keeps one feed for the whole company - the real stock count, not a branch-by-branch guess.
2. Each branch gets its own consumer record and portal login, all pointed at the same feed. There's no child feed or margin involved - it's internal, not resale.
3. A branch manager's booking reduces the same shared stock count atomically, so if Riverside books the last three units of something, Uptown's portal shows zero available immediately.
4. Head office can see which branch booked what in the plain-English activity log and the bookings grid, filtered by branch.
5. When a branch closes or a manager leaves, head office revokes that one branch's login without touching any of the others.

One product feed, whichever format your system already speaks.

GreenLeaf Garden — the download-link partner from Case study 2, keeping three of their own systems in sync

Before Feedwyre, Northwind emailed GreenLeaf a spreadsheet once a month, in whatever format happened to come out of Northwind's own system that day. Every month, someone at GreenLeaf reformatted that one file three different ways by hand: reordering columns to match their online store's bulk importer, resaving it for their bookkeeping software, and retyping a subset into the file their point-of-sale vendor's overnight sync script expected. Three manual reformats of one file, every month, each one a chance to introduce an error.

GreenLeaf's child feed download link (the same one from Case study 2) already carries their always-current, margin-priced catalog. It can serve that catalog as CSV, XLSX, or JSON from the same link, just by asking for a different format. Nothing changed about the feed itself - GreenLeaf simply pointed each of their three systems at the format it already knew how to read.

How it's set up

1. GreenLeaf already has a download link into their own child feed from Case study 2, so there's nothing new to request from Northwind.
2. Their online store's bulk product importer is pointed at the link's CSV form, on a daily schedule the store platform controls itself.
3. Their bookkeeper bookmarked the XLSX form and opens it straight in a spreadsheet each week for stock reconciliation, with no download-then-convert step.
4. A five-line script on their point-of-sale system pulls the JSON form overnight and refreshes on-shelf listings. It's small enough that nobody had to write a real integration.
5. When Northwind updates a cost price, the change reaches GreenLeaf's child feed and shows up, already re-priced at their agreed margin, in whichever format is opened next.

Two messy sources, one always-current product feed.

Bramble & Ash — a homeware manufacturer merging a legacy database with a hand-run spreadsheet

Bramble & Ash's core 12,000-item range lives in a warehouse SQL Server that predates most of the current team, and nobody wants to touch it directly. Limited-run seasonal drops, on the other hand, are tracked by hand in a spreadsheet, since they're short-lived and don't fit the warehouse system's workflow. Before every marketplace upload, someone had to reconcile both by eye.

Now the warehouse database syncs into a Feedwyre feed automatically on a schedule, and the seasonal spreadsheet gets imported in Merge mode whenever a new drop is ready. It only touches the rows it maps, so the synced items are never disturbed. The storefront and marketplace tooling call one feed instead of stitching two sources together.

How it's set up

1. A read-only database connection is registered against the warehouse SQL Server, with a query and column mapping for the core range.
2. Database sync is scheduled hourly. Feedwyre pulls fresh rows and merges them in, and a safety check stops the target from ever resolving to an internal network address.
3. When a seasonal drop is ready, the product team imports its spreadsheet in Merge mode, mapping columns once - only the mapped fields on the matched rows change.
4. Every change from either source lands in the same plain-English audit trail, so anyone can see exactly what came from the sync versus the manual import.
5. The storefront and marketplace tooling call the one resulting feed, so there's no more reconciling two sources before an upload. The merchandising team, who just want a spreadsheet to eyeball, get a secured download link into the same feed instead of API access they'd never use.