Shopify koppelen: de Admin API rekent in punten, niet in verzoeken
Deze koppeling bestaat niet tot iemand hem laat bouwen. Er staat geen app van ons in een appstore, wij zijn geen Shopify-partner, en er is geen winkel waarin dit al draait. Wat wel bestaat is de documentatie van Shopify zelf, en die beschrijft een model dat afwijkt van wat boekhoudpakketten doen: niet het aantal verzoeken telt, maar wat elke vraag aan rekenwerk kost. Wie dat begrijpt, snapt ook waarom een webshopkoppeling anders wordt gebouwd dan een administratiekoppeling.
Gepubliceerd op
Bestaat deze koppeling al?
Status van deze koppeling: op aanvraag. Concreet: hij is niet gebouwd, niet in een winkel geïnstalleerd, en er is geen demo van te geven. Wil je hem, dan begint dat met het intakegesprek en niet met een installatieknop. Wat het bouwen vraagt aan tijd, zeggen we pas als duidelijk is welke vragen hij moet beantwoorden — dat is per winkel verschillend genoeg om er geen standaardantwoord op te geven.
Wat de site hier verder over zegt, zegt hij overal hetzelfde: koppelingen zijn maatwerk en komen na het intakegesprek. Wat een AI-collega vandaag wél doet, is e-mail en WhatsApp Business afhandelen. Alles hieronder gaat dus over wat een koppeling zou vragen, niet over iets dat klaarstaat.
Hoe Shopify het gebruik van de Admin API begrenst
| Mechanisme | Wat Shopify erover documenteert |
|---|---|
| Manier van begrenzen | Op berekende querykosten: je kijkt naar de kosten van verzoeken over tijd, niet naar het aantal |
| Waar de limiet aan vastzit | Aan de combinatie van app en winkel; aanroepen van de ene app raken de limiet van een andere niet |
| Grens aan doorbladeren | Paginering door lijsten met objecten stopt bij 25.000 objecten |
| Wat er bij elk verzoek meegaat | Een access token dat de app authenticeert en de scopes draagt die bepalen wat hij mag zien |
| Beschikbaar bij Novot AI? | Op aanvraag — er is geen app, geen installatie en geen Shopify-partnerschap |
Punten in plaats van verzoeken, en waarom dat de bouw verandert
Shopify schrijft dat aanroepen naar de GraphQL Admin API worden begrensd op berekende querykosten, en dat je dus moet kijken naar wat verzoeken over tijd kosten in plaats van naar hoeveel het er zijn. Onder water is dat een emmer die per seconde een beetje leegloopt: een zware vraag gooit er meer in dan een lichte, en zit de emmer vol, dan krijg je een foutmelding tot er weer ruimte is.
Voor klantcontact pakt dat gunstig uit, mits je precies vraagt. "Wat is de status van bestelling X" is één gerichte query. "Geef me alle bestellingen van dit kwartaal met alle regels erbij" gebruikt dezelfde API maar een veelvoud aan punten. Een koppeling die op de eerste manier gebouwd is, merkt de limiet nooit; een koppeling die op de tweede manier gebouwd is, merkt hem elke ochtend om acht uur.
De limiet hangt aan app én winkel, en dat is goed nieuws voor je bestaande apps
Shopify koppelt de limiet van de GraphQL Admin API aan de combinatie van app en winkel: aanroepen van de ene app raken de limiet van een andere app niet, zelfs niet in dezelfde winkel. Dat is precies andersom dan bij een rem per IP-adres, waar alles wat vanaf één plek praat hetzelfde budget deelt.
Praktisch betekent dat: je verzendtool, je reviewsysteem en je boekhoudkoppeling worden niet trager doordat er iets bijkomt. Wat je ervoor inlevert is dat elke koppeling zijn eigen token en zijn eigen scopes heeft, en dus zijn eigen beheer. Een access token authenticeert de app en draagt de scopes die bepalen wat hij mag ophalen; Shopify dwingt die bij elk verzoek af en levert alleen terug wat ze toestaan. Daardoor is de vraag "wat mag deze koppeling zien" te beantwoorden zonder in de code te kijken — je leest het af aan de scopes waarmee hij geïnstalleerd is.
Wat een webshopvraag echt nodig heeft, en waar je moet ophouden met lezen
De vragen die in een webshop binnenkomen zijn opvallend voorspelbaar: waar is mijn pakket, kan ik nog wisselen van maat, klopt dit bezorgadres nog, hoe stuur ik iets terug. Daarvoor is één bestelling nodig, niet de hele catalogus en niet het hele klantenbestand.
Shopify begrenst het doorbladeren van lijsten met objecten bovendien op 25.000 objecten. Dat is een technische grens die precies dezelfde kant op wijst als de juridische: haal op wat de vraag nodig heeft en niet meer. Een koppeling die begint met "alles ophalen en dan filteren" loopt tegen allebei die grenzen aan, en tegen de tweede het hardst.
Dat betekent ook iets voor de opbouw van een gesprek. De AI-collega moet eerst uit het bericht halen om welke bestelling het gaat — een ordernummer, een e-mailadres, een naam met een datum — voordat er ook maar iets wordt opgevraagd. Doet hij dat niet, dan wordt hij een zoekmachine door jouw winkel, en dat is precies wat je niet wilt bouwen.
Wat we van je winkel moeten weten voordat hier iets gebouwd wordt
- De vragen die je klantenservice nu het vaakst in de Shopify-admin opzoekt, en ongeveer hoe vaak per dag dat gebeurt.
- Welke apps er al in de winkel staan, zodat we niet iets bouwen wat er al is.
- Wie in jouw team apps mag installeren en scopes mag goedkeuren — dat is een beslissing over toegang, niet over techniek.
- Of je meerdere winkels hebt: per winkel is het een eigen installatie met eigen sleutels en een eigen limiet.
De volgorde waarin wij werken staat bij onze aanpak. Wat daar niet staat en hier wel: een webshopkoppeling is pas zinvol als de statusvraag ook echt de meest gestelde vraag is. Dat is in veel webshops zo, maar niet in alle — bij een winkel die vooral advies verkoopt in plaats van pakketten gaat het gesprek over maten, materialen en geschiktheid, en daar helpt de bestelling je niet.
Wat er wettelijk geldt zodra een koppeling persoonsgegevens uit een pakket haalt — je haalt niet meer op dan nodig, en je legt vast wie verwerkingsverantwoordelijke is — staat uitgewerkt in AI en de AVG voor het MKB. Welke kanalen een AI-collega bij ons bedient, staat op de kanaalpagina over e-mail.