Hoe lang duurt een volledige synchronisatie? Doorvoer berekenen

De som

Doorvoer is het aantal records dat een koppeling per minuut of per dag door een API krijgt. De duur van een volledige ronde volgt uit drie getallen: hoeveel records er zijn, hoeveel aanroepen één record kost en hoeveel aanroepen de API toelaat.

duur = records x aanroepen per record / limiet per minuut

15.000 artikelen x 1 aanroep = 15.000 aanroepen
15.000 / 60 per minuut       = 250 minuten = 4 uur en 10 minuten

Elk van de drie getallen valt in de praktijk hoger of lager uit dan gedacht.

Records. Tel varianten, niet producten. 3.000 producten met gemiddeld 5 varianten zijn 15.000 records, want elke variant heeft een eigen voorraad en een eigen artikelnummer.

Aanroepen per record. Staat de voorraad in het ene endpoint en de prijs in het andere, dan kost een artikel 2 aanroepen en wordt 250 minuten 500 minuten.

Limiet. Een API heeft er vaak meer dan één. Exact Online telt per minuut en per dag. Bij 5.000 aanroepen per dag duren 15.000 aanroepen drie dagen, hoe snel je ze ook verstuurt. Het laagste plafond bepaalt de doorvoer.

Echte plafonds per systeem

De getallen hieronder komen uit de documentatie van de leveranciers, gecontroleerd op 3 oktober 2026.

Exact Online publiceert deze grenzen op de pagina API limits. Gewone endpoints geven daar 60 records per pagina terug, bulk- en sync-endpoints 1.000. Shopify noemt de REST Admin API sinds 1 oktober 2024 legacy en rekent in GraphQL met kosten per query in plaats van met een aantal aanroepen. Picqer kan de 500 per minuut tijdelijk verlagen als het platform druk is.

Er is ook een plafond dat niet in een API zit maar in de koppeling zelf. Een standaardkoppeling die voorraad in een vaste lus scant, bijvoorbeeld 10 producten per 5 minuten, verwerkt 120 producten per uur. Dat lijkt op elke 5 minuten synchroniseren. Per artikel is het iets anders:

Een artikel dat net gescand is en daarna uitverkoopt, staat bij 5.000 producten nog 42 uur als leverbaar in de webshop.

Hoe je de som verandert

De limiet ligt vast. De andere twee getallen niet.

Bundelen. Meer records per aanroep. Bij Exact Online 1.000 in plaats van 60 per pagina: 15 aanroepen in plaats van 250 voor dezelfde 15.000 artikelen. Bij Shopify 250 voorraadregels in één GraphQL-mutatie in plaats van één artikel per aanroep.

Delta in plaats van alles. Alleen ophalen wat gewijzigd is. De sync-endpoints van Exact Online werken met een Timestamp: je geeft de laatste waarde mee en krijgt alleen nieuwe en gewijzigde records terug. Verwijderde records zitten daar niet in. Die komen uit een apart endpoint, en een koppeling die dat overslaat laat verwijderde artikelen in de webshop staan.

Delta werkt niet overal voor voorraad. Veel ERP's zetten de wijzigingsdatum van een artikel alleen bij een wijziging in omschrijving of prijs, niet bij een voorraadmutatie. Een delta op artikelniveau mist dan elke verkoop en elke ontvangst. De oplossing is een bron die voorraadmutaties zelf markeert, zoals sync/Inventory/StockPositions bij Exact Online, met een volledige ronde per nacht als vangnet.

Snellopers eerst. Niet elk artikel verdient hetzelfde tempo. Neem 15.000 artikelen waarvan 1.500 snellopers. De snellopers elke 10 minuten en de overige 13.500 elke 4 uur is 1.500 x 6 + 13.500 / 4 = 12.375 records per uur. Alles elke 10 minuten is 90.000 records per uur. Bij 250 records per aanroep is dat 50 tegen 360 aanroepen per uur.

Spreiden. 5.000 aanroepen per dag is gemiddeld 208 per uur. Een nachtelijke prijsronde die er 2.000 gebruikt, laat voor de rest van de dag 3.000 over. Zware rondes plan je buiten de uren waarin orders binnenkomen. Hoe je per stroom het tempo kiest staat in realtime of batch.

Parallel werken helpt beperkt. Business Central verwerkt per gebruiker 5 aanvragen tegelijk, NetSuite op het Standard-niveau 5 per account, gedeeld met elke andere koppeling op dat account. Tien processen naast elkaar leveren daar geen dubbele doorvoer op, wel geweigerde aanvragen.

Piekdagen

Een koppeling die op een gewone dinsdag ruim binnen de limiet blijft, kan op de drukste dag van het jaar vastlopen. Reken het door voor Exact Online met 150 orders per dag.

• Orders: 150 x 4 aanroepen = 600. De vier zijn: debiteur opzoeken, artikel-ID opzoeken voor gemiddeld 2 orderregels, order aanmaken.
• Voorraad: een delta elke 10 minuten is 144 rondes x 2 aanroepen = 288.
• Prijzen en artikelen, per nacht: 30.

Samen 918 van de 5.000. Op een piekdag met tien keer zoveel orders wordt de eerste regel 1.500 x 4 = 6.000 en het totaal 6.318. Het dagbudget is op bij order 1.170, want (5.000 min 318) / 4 = 1.170. De overige 330 orders komen pas de volgende dag in het ERP.

De limiet verandert niet, het aantal aanroepen per order wel. Houdt de koppeling de artikel-ID's in een eigen tabel bij, dan vallen de 2 opzoekacties per order weg en kost een order 2 aanroepen. Dezelfde piekdag komt dan op 3.000 + 318 = 3.318, met 1.682 aanroepen over voor herhaalpogingen.

De minuutlimiet telt ook mee. Komen er 200 orders in 10 minuten binnen, dan zijn dat bij 2 aanroepen per order 400 aanroepen. Bij 60 per minuut duurt het verwerken 6 minuten en 40 seconden. De orders staan zolang in een wachtrij en de webshop merkt er niets van. Zonder wachtrij krijgt order 31 in die minuut een 429 terug. Wat er dan gebeurt staat in wat is een rate limit.

API-limieten en een ronde met 15.000 artikelen

Elke API begrenst hoeveel verzoeken je per seconde, per minuut of per dag mag doen. Die grens bepaalt hoe lang een ronde duurt, en daarmee hoe actueel je webshop is.

De getallen zijn op 3 oktober 2026 nagelezen in de documentatie van Shopify, Picqer en Exact Online.

Een rekenvoorbeeld. Een groothandel heeft 15.000 artikelen in het ERP. De API staat 60 verzoeken per minuut toe.

• Een artikel per verzoek. 15.000 verzoeken gedeeld door 60 is 250 minuten: 4 uur en 10 minuten voor één ronde. Bij een daglimiet van 5.000 verzoeken duurt dezelfde ronde drie dagen.
• Alleen wat gewijzigd is. Bij 600 wijzigingen sinds de vorige ronde zijn het 600 verzoeken: 10 minuten.
• 100 artikelen per verzoek. 150 verzoeken: 2,5 minuut.

De koppeling combineert de laatste twee: per ronde alleen de wijzigingen, in zo groot mogelijke pagina's, met een wachtrij die de verzoeken over de minuut spreidt. Loopt hij toch tegen de grens, dan antwoordt de API met een 429. Bij Exact Online ziet dat er zo uit:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Minutely-Limit: 60
X-RateLimit-Minutely-Remaining: 0
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 3812

De koppeling leest die regels uit, wacht tot de minuut voorbij is en gaat verder waar hij was. De eerste twee regels zijn de minuutlimiet, de laatste twee het dagbudget: er zijn vandaag nog 3.812 verzoeken over. De som voor je eigen aantallen maak je met doorvoer berekenen; wat een limiet precies is staat in wat is een rate limit.

Toegang en limieten per systeem

Drie verschillen die de opzet van een koppeling bepalen. Exact Online geeft toegang per administratie: een tweede administratie is een tweede verbinding met een eigen limiet van 60 verzoeken per minuut. AFAS werkt met GetConnectoren om te lezen en UpdateConnectoren om te schrijven, en de beheerder van AFAS stelt ze beschikbaar voordat er iets gekoppeld kan worden. Picqer heeft een open API met 500 verzoeken per minuut en webhooks, en leest zelf geen leveranciersbestanden in.

Wat betekent dit voor je koppeling?

Wij maken deze som voordat er iets gebouwd wordt: het aantal artikelen en varianten, het aantal orders op een gewone dag en op je drukste dag, en de limieten van de systemen die je gebruikt. Daaruit volgt welke stroom gebundeld gaat, welke als delta en hoe groot de wachtrij moet zijn. In het dashboard zie je per ronde hoeveel records verwerkt zijn en hoe lang dat duurde.

Voor voorraad staat de uitwerking op voorraad koppelen. Hoe de stromen tussen webshop en ERP samenhangen lees je in je webshop koppelen aan je ERP. Wil je de som voor jouw aantallen zien, stuur ze dan in.