Elke aanroep die een custom Shopify app doet naar Shopify's API's - orders ophalen, voorraad bijwerken, klantdata synchroniseren, fulfilment activeren - telt mee voor een rate limit. Overschrijd die limiet en Shopify vertraagt of blokkeert verdere verzoeken totdat de limiet is hersteld.
Voor laag-volume webshops die een handvol bestellingen per uur verwerken, is dit zelden een probleem. Voor ondernemers die honderden bestellingen verwerken tijdens een piekperiode, of nachtelijke syncs uitvoeren die duizenden producten raken, worden API-limieten een kritieke engineering-overweging.
Dit artikel legt uit hoe Shopify's rate limits werken, wat er gebeurt als je ze raakt, en hoe goed-gearchitectureerde custom apps er betrouwbaar mee omgaan.
Hoe Shopify's API rate limiting werkt
De REST Admin API - leaky bucket model
Shopify's REST Admin API gebruikt een leaky bucket model. Je app heeft een emmer met een capaciteit van 40 verzoeken. De emmer loopt leeg tegen een snelheid van 2 verzoeken per seconde. Als je app verzoeken doet sneller dan de emmer leegloopt, vult hij op. Wanneer de emmer vol is, retourneert Shopify een 429 Too Many Requests fout en moet je app wachten voor het opnieuw te proberen.
De praktische implicatie: een goed-beheerde app kan ongeveer 2 verzoeken per seconde onbeperkt volhouden. Een burst van maximaal 40 verzoeken kan direct plaatsvinden, waarna de app moet terugkeren naar het duurzame tempo.
De GraphQL Admin API - berekende query-kosten
De GraphQL Admin API gebruikt een kostengebaseerd systeem. Elke query heeft een berekende kostprijs op basis van de gevraagde velden en de datacomplexiteit. Je app heeft een kostenbudget van 1.000 punten dat aanvult tegen 50 punten per seconde.
Eenvoudige queries kosten relatief weinig. Queries die veel velden over veel objecten opvragen - 250 bestellingen ophalen met alle regelitems, klantdata en fulfilmentdetails in een enkele aanroep - kunnen enkele honderden punten kosten. Structureer je queries om alleen te vragen wat je nodig hebt.
De Storefront API
De Storefront API heeft aparte rate limits van de Admin API. Hij is ontworpen voor hogere volumes, klantgerichte operaties en is over het algemeen meer permissief. Hij stelt echter een smallere set data bloot en is niet geschikt voor backend-operaties die toegang nodig hebben tot orderbeheer of voorraad.
Webhooks
Webhooks zijn Shopify's push-mechanisme - Shopify stuurt een melding naar je app wanneer er iets gebeurt. Ze tellen niet mee voor je API rate limit aan de ontvangende kant, maar je app moet wel binnen 5 seconden reageren of Shopify markeert de levering als mislukt en probeert opnieuw.
Webhook-levering is niet gegarandeerd. Shopify probeert mislukte leveringen tot 19 keer opnieuw gedurende 48 uur, maar als je app langer dan dat niet beschikbaar is, gaan die events verloren. Apps die afhankelijk zijn van webhooks voor kritieke datastromen hebben een reconciliatiemechanisme nodig.
Wanneer API-limieten een probleem worden
Hoog-volume orderverwerking
Een ondernemer die 500 bestellingen per uur verwerkt over meerdere fulfilment-partners, waarbij elke bestelling API-aanroepen vereist om orderdata te lezen, voorraad te controleren en fulfilment te activeren, kan de duurzame snelheid tijdens piekperioden gemakkelijk overschrijden. Zonder rate limit-afhandeling faalt de integratie precies wanneer die het meest nodig is.
Grootschalige datasyncs
Nachtelijke syncs die productdata van een PIM naar Shopify pushen - prijzen, voorraad, beschrijvingen en varianten bijwerken over een catalogus van 10.000 producten - vereisen zorgvuldige API-aanroepplanning. Bij 2 verzoeken per seconde voor de REST API duurt een naieve implementatie die per productupdate een API-aanroep doet, meer dan 80 minuten. Een goed-ontworpen implementatie met bulk-operaties reduceert dit tot minuten.
Multi-store architecturen
Ondernemers die meerdere Shopify-webshops beheren met een gedeelde backend, moeten API-limieten per webshop beheren. Elke webshop heeft zijn eigen onafhankelijke rate limit emmer. Een app die 5 webshops tegelijk beheert, moet 5 aparte rate limit-staten beheren.
Realtime integraties
Integraties die in realtime moeten reageren - voorraad controleren voor een bestelling bevestigt, het accountsaldo van een klant ophalen tijdens checkout, voorraad bijwerken op het moment dat een verkoop is voltooid - hebben geen tolerantie voor rate limit-vertragingen. Deze vereisen architecturen die data lokaal cachen en asynchroon bijwerken, in plaats van synchrone API-aanroepen op het moment van behoefte.
Hoe goed-gearchitectureerde apps omgaan met rate limits
Exponential backoff en retry-logica
Elke API-aanroep in een correct gebouwde app is omhuld met retry-logica. Wanneer een 429-respons wordt ontvangen, wacht de app - beginnend met een korte vertraging en die bij elke volgende poging verdubbelen tot een maximum. Dit is exponential backoff. Zonder dat faalt een app die een rate limit raakt ofwel volledig, ofwel bombardeert de API met directe herhaalpogingen, waardoor de situatie verslechtert.
Verzoekwachtrij
In plaats van API-aanroepen direct te doen wanneer een event plaatsvindt, plaatst een goed-ontworpen app verzoeken in een wachtrij en verwerkt ze met een snelheid die de API-limiet respecteert. De wachtrij absorbeert verkeersprieken en zorgt voor soepele, betrouwbare werking zelfs tijdens piekperioden.
Bulk-operaties voor grote datasets
Shopify's Bulk Operations API laat apps grote datasets asynchroon opvragen. In plaats van 10.000 producten op te halen in batches van 250 met veel API-aanroepen, haalt een bulk-operatie alle 10.000 op in een enkel verzoek dat Shopify op de achtergrond verwerkt en als bestand levert. Dit is dramatisch efficiënter voor grootschalige dataoperaties.
Caching van veelvuldig-geraadpleegde data
Data die frequent wordt gelezen maar zelden verandert - productcatalogi, klantgroepen, prijslijsten - moet lokaal worden gecached in plaats van bij elk verzoek van de API te worden opgehaald. Een cache met een verstandige TTL (time to live) vermindert API-aanroepvolume aanzienlijk en maakt de integratie veerkrachtiger voor rate limit-events.
Webhook-reconciliatie
Apps die afhankelijk zijn van webhooks voor kritieke datastromen, moeten een reconciliatieproces implementeren - een periodieke batch-job die de API direct bevraagt om events te identificeren die webhooks mogelijk hebben gemist. Dit zorgt voor dataconsistentie zelfs wanneer webhook-levering faalt.
Wat dit betekent bij het evalueren van een custom app-voorstel
Wanneer je een voorstel ontvangt voor een custom Shopify app, is de kwaliteit van de rate limit-afhandeling een van de duidelijkste signalen van het ervaringsniveau van de ontwikkelaar. Vragen om te stellen:
- Hoe ga je om met 429 rate limit-responsen? Wat is je retry-strategie?
- Gebruik je voor grote datasyncs de Bulk Operations API?
- Hoe ga je om met mislukte webhook-leveringen? Is er een reconciliatieproces?
- Heb je de integratie load-getest tegen de volumes die we verwachten tijdens piekperioden?
- Wat gebeurt er met bestellingen tijdens een periode dat de API niet beschikbaar is?
Ontwikkelaars die geen apps op schaal hebben gebouwd, hebben vaak goede antwoorden voor normale bedrijfsomstandigheden en slechte antwoorden voor storingen. De storingen zijn wat het meest telt in productie.
Een app die werkt in tests en faalt onder piekbelasting, is geen opgeleverde app. Rate limit-afhandeling is geen optionele engineering - het is het verschil tussen een custom integratie die een bedrijfsactief is en een die een operationele aansprakelijkheid is.