Een grote catalogus inladen in je webshop: zo controleer je 14.500 varianten

Wat is anders aan een grote catalogus?

Een catalogus van 200 producten loop je na door de webshop door te klikken. Een catalogus van 4.000 producten met 14.500 varianten niet: met 10 seconden per variant ben je 40 uur bezig, en je ziet nog niet wat ontbreekt. Een kleding- of installatiecatalogus komt snel op die getallen. Een product in 4 kleuren en 6 maten is al 24 varianten.

Drie dingen veranderen bij die omvang. Het inladen gaat via de bulkroute van het platform, niet via losse verzoeken. Fouten worden tegengehouden voordat ze erin gaan, niet achteraf opgezocht. En de controle achteraf zijn regels die over de hele catalogus draaien. Waar de productdata vandaan komt, ERP, PIM of leveranciersbestand, maakt voor die drie niet uit. Hoe een PIM de bron kan zijn staat in wat is een PIM-systeem.

Hoe laad je duizenden producten in?

Elk platform heeft een eigen route voor grote aantallen. Nagelezen in de documentatie op 3 oktober 2026:

Rekenvoorbeeld: 4.000 producten, 14.500 varianten

Lezen uit het ERP. Exact Online geeft 1.000 regels per verzoek: 14.500 gedeeld door 1.000 is 14,5, dus 15 verzoeken. Dat is 0,3% van de 5.000 verzoeken per dag.

Schrijven naar Shopify. Eén bulkoperatie met een bestand van 4.000 regels. Rekenen we 2 KB per regel voor een product met gemiddeld 3,6 varianten, dan is het bestand 8 MB, ruim onder de 100 MB. Een bulkoperatie telt niet mee voor de rate limit. Hetzelfde met losse productSet-aanroepen kost per aanroep minstens 10 punten. 4.000 x 10 is 40.000 punten, bij 100 punten per seconde op een standaardabonnement minstens 400 seconden, en in de praktijk meer omdat een product met varianten meer punten kost.

Schrijven naar WooCommerce. Producten gaan in batches van 100: 4.000 gedeeld door 100 is 40 verzoeken. Varianten hebben een eigen batch per product, dus minstens 4.000 verzoeken, en meer voor een product met meer dan 100 varianten. Samen minstens 4.040.

Een bulkbestand in Shopify bevat per regel de gegevens van één product. Zo ziet zo'n regel eruit, hier over meer regels verdeeld om te lezen:

{
  "identifier": { "handle": "werkbroek-1048" },
  "input": {
    "title": "Werkbroek 1048",
    "productOptions": [
      { "name": "Kleur", "values": [{ "name": "Zwart" }, { "name": "Navy" }] },
      { "name": "Maat", "values": [{ "name": "48" }, { "name": "50" }] }
    ],
    "variants": [
      { "sku": "1048-BLK-48", "price": "54.95",
        "optionValues": [{ "optionName": "Kleur", "name": "Zwart" },
                         { "optionName": "Maat", "name": "48" }] }
    ]
  }
}

Twee details doen ertoe. De handle is de sleutel: dezelfde handle bij een tweede ronde werkt het bestaande product bij in plaats van een tweede te maken. En Shopify verwerkt de regels niet op volgorde. Een regel mag dus niet afhangen van een regel erboven.

Wat moet er kloppen voordat je inlaadt?

De controle vooraf houdt regels tegen die het platform wel zou accepteren maar die fout zijn. In het voorbeeld zijn dat 54 producten met 212 varianten, en ze komen op een controlelijst met de reden erbij:

De varianten zelf zijn het grootste risico. Een ERP dat elke kleur als los artikel voert, levert 14.500 losse producten op in plaats van 4.000 producten met varianten, tenzij de koppeling ze groepeert. Hoe dat gaat staat bij varianten.

Negen controles na het inladen

Na het inladen draaien controles over de hele catalogus. Bij een migratie van 4.000 producten en 14.500 varianten zijn dit de negen die ertoe doen:

1. Aantallen. Producten en varianten in de bron tegen de webshop: 3.946 en 14.288 ingeladen, plus 54 en 212 op de controlelijst, is 4.000 en 14.500.
2. Aantallen per categorie of collectie. Een categorie die van 320 naar 0 gaat, wijst op een mapping die niet past.
3. Maten en kleuren. Elke optiewaarde komt voor in de vaste lijst.
4. Prijs en actieprijs. Geen prijs van 0, geen actieprijs boven de prijs, en de prijs komt overeen met het ERP.
5. Afbeeldingen. Elk product heeft een hoofdafbeelding, en een variant met een eigen foto wijst naar de goede.
6. Voorraad. De stand komt uit het systeem dat leidend is voor voorraad, niet uit de oude webshop.
7. Lege velden. Elk product met een leeg verplicht veld staat op een lijst, met het veld erbij.
8. Filters. Combinaties die weinig voorkomen geven resultaat, bijvoorbeeld maat 64 in navy.
9. Oude URL's. Elk adres uit de oude webshop leidt naar het nieuwe product.

Het resultaatbestand van Shopify helpt bij de eerste controle. Elke regel in dat bestand hoort bij een regel uit het invoerbestand, met de fout of het nieuwe ID erbij. Een bulkoperatie mislukt alleen in zijn geheel bij een fout aan de kant van Shopify; fouten in afzonderlijke regels staan per regel in het resultaat.

Een catalogus in een winkel met al veel producten loopt tegen nog een grens aan. Vanaf 500.000 varianten in een winkel mogen er per dag maximaal 10.000 nieuwe bij, behalve op Shopify Plus. 14.500 nieuwe varianten gaan dan over 2 dagen. Hoe Shopify verder begrenst staat in Shopify API limieten.

Wat betekent dit voor je koppeling?

Het inladen zelf is in het voorbeeld 15 verzoeken en één bulkoperatie. Of de catalogus daarna klopt, hangt af van de regels vooraf en de controles achteraf. Wij bouwen de koppeling die de catalogus uit je ERP of PIM leest, hem tegen jouw regels controleert, de bulkroute van je webshop gebruikt en per run laat zien wat erin ging, wat werd tegengehouden en waarom. Een dry run laat dat zien voordat er iets in de webshop staat.

Daarna gaan alleen wijzigingen, met dezelfde controles. Het overzicht van de productstromen staat op productdata en catalogus. Vertel hoeveel producten en varianten je hebt, en waar ze nu staan.