Hoe voorkom je fouten wanneer je productdata naar meerdere marketplaces stuurt?

Question

Wij verkopen producten via onze eigen webshop en willen daarnaast uitbreiden naar meerdere marketplaces. Op dit moment worden productinformatie, prijzen en voorraad nog grotendeels handmatig bijgewerkt.

We merken dat dit steeds meer tijd kost en dat er fouten ontstaan. Bijvoorbeeld een verkeerde voorraad, dubbele producten, ontbrekende specificaties of een prijs die op het ene platform wel is aangepast en op het andere niet.

Daarom onderzoeken we of we dit centraal kunnen beheren met een eigen koppeling of SaaS-oplossing. Het idee is dat productdata uit Shopify wordt opgehaald, centraal wordt opgeslagen en vervolgens automatisch naar verschillende marketplaces wordt doorgestuurd.

Bestellingen moeten daarna weer naar Shopify of ons fulfilmentsysteem worden teruggestuurd.

Ik ben vooral benieuwd naar ervaringen van ondernemers of developers die dit al hebben gebouwd of geïmplementeerd.

Waar ging het bij jullie in de praktijk mis?
Welke productgegevens slaan jullie centraal op?
Hoe gaan jullie om met verschillende categorieën en verplichte attributen per marketplace?
Gebruiken jullie webhooks, periodieke synchronisatie of een combinatie?
Is een bestaande oplossing uiteindelijk voordeliger dan zelf ontwikkelen?

Ik zoek niet direct een specifiek softwarepakket, maar vooral praktijkervaringen en aandachtspunten voordat we hier veel tijd en geld in investeren.

Angelo · Accepted Answer

Wij hebben precies dit gebouwd recentelijk (Shopify → centrale laag → meerdere marketplaces, orders weer terug). Een paar dingen die ik vooraf had willen weten:

De belangrijkste beslissing vooraf: wie is eigenaar van welk veld?

Iedereen roept "single source of truth", maar dat wordt vaak verkeerd begrepen. SSOT betekent níét dat alle data van één systeem komt. Het betekent dat elk veld precies één eigenaar/schrijver heeft. Zodra twee systemen hetzelfde veld mogen aanpassen (prijs in Shopify én op de marketplace) krijg je conflicten en eindeloze ping-pong.

Wij hebben het zo verdeeld:

De productdata (titel, specs, foto's) heeft Shopify als eigenaar — of de marketplace-operator zelf — en die stroomt één kant op, naar onze centrale laag toe (wij lezen alleen).

De prijs en voorraad zijn van onze centrale laag; die schrijven wíj weg naar de marketplace. En bestellingen zijn van de marketplace; die lezen wij op en sturen we door naar Shopify / het fulfilmentsysteem.

Netto is dat een two-way sync op systeemniveau, maar strikt one-way per veld. Dat is het verschil tussen een systeem dat schaalt en één dat je elke week zit te debuggen. Echte bidirectionele sync van hetzelfde veld: niet doen.

Waar we in de praktijk van geleerd hebben

SKU als sleutel gebruiken. Grootste fout. SKU's veranderen (iemand hernoemt een variant) en elke marketplace verzint z'n eigen interne ID. De enige echt stabiele koppel-sleutel is de EAN/GTIN. Sla die op en match daar overal op. Wij hadden orders die niet te matchen waren omdat de SKU na het aanbieden was gewijzigd — via de EAN losten we dat op.
Scoping/tenancy. Eén verkeerd gekoppeld ID (welke data hoort bij welke shop/koppeling) en je bent een dag kwijt. Bouw dat vanaf dag één goed.
Het verschil tussen catalogus en offer niet snappen. Bij sommige marktplaatsen (Mirakl-based bv.) mag je niet zomaar producten via de API aanmaken — daar zijn speciale rechten of een goedkeuringstraject voor. Je "offer" (prijs/voorraad) plakt op een bestaand catalogus-product via de EAN.
Snap je dat verschil niet, dan krijg je duplicaten of geblokkeerde uploads. Wij zijn deels overgestapt op: catalogus laten beheren door de operator/portal, en zelf alleen offers pushen. Veel minder gedoe.
Geen idempotentie op orders. Zonder een idempotency-key maak je bij elke sync-run opnieuw dezelfde (concept-)order aan. Sla per externe order-ID op wat je al hebt aangemaakt.
API-eigenaardigheden per marketplace. Velden die net anders heten, filters die genegeerd worden, statussen die je moet pollen. Reken op verrassingen per platform.

Welke productdata we centraal opslaan

Een minimale canonieke set: een stabiele interne identifier, EAN, SKU, titel, prijs in centen als integer (nooit floats — afrondingsellende), voorraad, categorie, en een flexibel attributen-blob (JSONB) voor alles wat marketplace-specifiek is + bron-metadata (Shopify-ID's, afbeeldingen).

Plus een aparte status-tabel per product per marketplace: is het gepubliceerd, een change-hash, laatste foutmelding, en of de marketplace het product al kent. Die status-tabel is goud voor debuggen en voor een dashboard.

Categorieën en verplichte attributen per marketplace

Dit is verreweg het lastigste stuk, en waar de meeste tijd in gaat zitten. Elke marketplace heeft z'n eigen categorieboom én eigen verplichte attributen, met eigen regels. De één dwingt precies één categorie af; de ander levert "core"-attributen onder élke tak. Er is geen one-size-fits-all.

Wij hebben een mapping-laag gebouwd: eigen categorie → marketplace-categorie, plus per-attribuut een koppeling (onze veldnaam → hun attribuutcode), opgeslagen als config (JSONB) per categorie — niet hardcoden.

Abstraheer per marketplace. Probeer niet één generiek model over alle platformen te trekken, dat breekt gegarandeerd.

Webhooks, periodiek of combinatie?

Combinatie, altijd.

Productdata inbound: periodieke bulk-sync (Shopify heeft bulk export). Webhooks zijn leuk als versneller, maar ze missen events — je hébt een periodieke reconciliation nodig als waarheid.
Orders: kort interval (elke paar minuten) of webhooks — tijdgevoelig.
Offers outbound: change-detection met een hash/fingerprint per offer, zodat je alleen wijzigingen pusht en niet elke run je hele catalogus. Dat scheelt enorm in rate limits.

Een vaste regel bij mij: webhooks als versneller, periodieke sync als vangnet en bron van waarheid. Vertrouw nooit alleen op webhooks.

Zelf bouwen of kopen?

Ik denk, heb je standaard-marktplaatsen (Bol, Amazon) met standaard-behoeften? Koop iets (Channable, ChannelEngine, EffectConnect). Sneller en goedkoper.

Zelf bouwen loont alleen als je niche-/atypische marktplaatsen hebt die de standaardtools niet goed dekken, specifieke
fulfilment-flows, of als deze koppeling je kernproduct ís.

De 80/20 is meedogenloos: de happy path bouw je in een week. De laatste 20% edge cases, API-quirks, idempotentie, foutrapportage, en vooral die mapping-UI voor categorieën/attributen kost maanden.

En marketplace-API's veranderen: je tekent voor doorlopend onderhoud, niet voor een eenmalig project.

Hoe voorkom je fouten wanneer je productdata naar meerdere marketplaces stuurt?

Log in om te reageren