Discogs WooCommerce sync case study. Problem: VinylSync, a multi-tenant SaaS that keeps a record store's Discogs listings and WooCommerce shop in step, had never been proven on a real catalogue, and a one-of-a-kind record must never be sold twice. What we did: built a full staging environment, found and fixed data-integrity and access-control bugs, and rebuilt sold-sync as three layers (instant webhooks, order polling and two-way state reconciliation). Result: two-way availability sync verified end to end on 869 WooCommerce products and 333 live Discogs listings, with no duplicates and production untouched. Stack: Node.js, Express, Supabase (PostgreSQL), WooCommerce REST API, Discogs Marketplace API, Render.
- Product
- VinylSync, a multi-tenant SaaS for record stores
- Industry
- Music retail and e-commerce
- Test catalogue
- A working record store: 869 WooCommerce products, 333 live Discogs listings
- Stack
- Node.js, Express, Supabase (PostgreSQL), WooCommerce REST API, Discogs Marketplace API, Render
- Delivered by
- PlusTechnology
The product
Independent record stores sell the same copies of the same records in two places at once: the Discogs marketplace and their own WooCommerce shop. VinylSync is a multi-tenant SaaS for Discogs WooCommerce sync: it imports a store's Discogs inventory, writes the product pages, publishes them to WooCommerce and keeps stock in step between the two.
The core promise is simple, and expensive to break: a one-of-a-kind record must never be sellable twice.
The challenge
The app worked, but it had never been proven against a real catalogue, and there was nowhere safe to test. Pushing fixes straight to production meant risking live listings and live orders. The brief: find and fix the bugs without breaking what already worked, then prove the result with evidence.
Our approach
- A real staging environment first. A full copy of the stack with its own database, its own hosted service and a staging branch that deploys automatically. Production was never touched during the work.
- Audit, then fix, with a written trail. Every fix went into a changelog with the cause, the evidence and the verification.
- Test against real data, not fixtures. The final test store was a working shop with 869 WooCommerce products and 333 live Discogs listings.
What broke, and how we fixed it
| Problem found | Why it mattered | Fix |
|---|---|---|
| A real order never reached Discogs; the item stayed for sale | Risk of selling the same record twice | Rebuilt sold-sync as three independent layers |
| Webhook lookups weren't scoped per store | One store's sale could mark another store's record sold | Per-store webhook URLs and store-scoped lookups |
| Sync could mark items sold but never undo it | Manual restocking left the two sides out of step | Two-way reconciliation of actual state |
| A second copy of a record merged into the first copy's product | The wrong product was overwritten | Products linked to another listing can't be claimed |
| Only the newest 5 listings were ever imported | 328 of 333 listings were unreachable | Fetch the full inventory; cap limits imports per run only |
| Overlapping syncs imported the same listing twice | Duplicate listings and products | Per-store run locks plus a database uniqueness rule |
| Autopilot dropped the link for existing products | Those products were ignored by sold-sync | Store the existing product's ID on adoption |
| Autopilot routes had no ownership check | Any logged-in partner could control any store's Autopilot | Ownership guard on every store-scoped route |
Sold-sync that survives reality
- Instant webhook per store: a WooCommerce order triggers an immediate Discogs update.
- Order polling every 5 minutes: catches orders if a webhook is missed or not configured.
- State reconciliation every 5 minutes: compares what is actually for sale on each platform and syncs whichever side is stale, including manual stock changes and reversals such as cancelled orders.
Making synced products look like the store's own
The store's 869 existing products followed a specific title and description layout from an earlier plugin. We reverse-engineered the rules from the live data (artist naming, join words, tracklist formatting, tags and category) and built a deterministic formatter that needs no AI call, configurable per store. Checked against the live storefront:
- Titles identical on 43 of 45 products compared.
- 97% of description lines reproduced exactly (1,156 of 1,188); the rest were Discogs-side edits made since the original import.
- Tags matched exactly on 52 of 66 products, with the rest explained by the same Discogs-side edits.
Re-publishing an existing product now leaves its URL, SKU, photos, category and tags untouched, and syncs only content, price and stock.
Verification
| Test step | Result |
|---|---|
| Publish an item that already exists in the shop | Linked to the existing product; no duplicate |
| Discogs listing set to Draft | WooCommerce item went out of stock |
| Discogs listing relisted | WooCommerce restocked |
| WooCommerce item set out of stock | Discogs listing drafted |
| WooCommerce item restocked | Discogs relisted |
| Real order placed on WooCommerce | Item marked sold, Discogs drafted |
| Order cancelled | Both sides restored |
| Two syncs started simultaneously | One imported, one skipped; no duplicates |
Autopilot was tested the same way: a new Discogs listing was imported, written up and published to WooCommerce automatically within one 5-minute cycle, with the right SKU, price and images and no duplicates. All test data was removed afterwards.
Results
- Two-way Discogs WooCommerce sync covering manual changes and real orders in both directions, verified against a real catalogue.
- Data-integrity and access-control bugs found and fixed before reaching production.
- Per-store connection health checks with plain-language errors on admin and partner dashboards.
- Product pages that match the store's format, with Rank Math SEO fields, categories and tags handled correctly.
- Production untouched until each change is explicitly promoted.
What we'd highlight
- Evidence over assumption. Answers came from logs, version history and live API calls. Several key bugs only appeared because of real data.
- Design for reversal, not just events. "Item sold" is only half the story; in a reliable Discogs WooCommerce sync, reconciliation handles the rest.
- Safe by default: staging first, locks and uniqueness rules against race conditions, ownership checks on every store-scoped route, and clean-up of every test fixture.
Discogs WooCommerce sync FAQ
How do you sync Discogs and WooCommerce inventory?
VinylSync uses three layers: an instant per-store webhook when a WooCommerce order arrives, order polling every 5 minutes in case a webhook is missed, and a reconciliation job every 5 minutes that compares what is actually for sale on both platforms and fixes whichever side is stale.
How do you prevent a record being sold twice on Discogs and WooCommerce?
Sales trigger an immediate Discogs update, missed events are caught by polling, and reconciliation handles manual stock changes and reversals such as cancelled orders. Per-store run locks and a database uniqueness rule stop duplicate imports.
Can one sync app safely serve many stores?
Yes, if every lookup is scoped per store. We added per-store webhook URLs, store-scoped lookups and ownership checks on every store-scoped route, and verified it with two stores sharing the same WooCommerce product ID.
How was the sync tested?
With an eight-step end-to-end test on staging against a real catalogue: publishing existing items, drafting and relisting on Discogs, stock changes in WooCommerce, a real order, a cancellation and two simultaneous syncs. Every step passed with no duplicates.
Related reading
- Our WooCommerce services
- WooCommerce vs Shopify in 2026
- AI automation workflows for small businesses
Want something similar for your business? Hire PlusTechnology on Upwork or get in touch.