Hoe zit het met de API limieten van de boekhoudpakketten?
Bij de meeste boekhoudpakketen is het mogelijk 150 tot 500 transacties per dag te boeken. Op jaarbasis met een gelijkmatige verdeling in de tijd is er tot 50.000 transacties/jaar dus geen probleem. En daarmee kunnen we gelukkig >98% van de klanten uitstekend helpen.
Sommige boekhoudpakketten hebben bewust een gedocumenteerde harde API limiet (vb Exact Online per uur, en daarnaast ook per dag). Sommige boekhoudpakketten (vb Visma-Yuki of Silvasoft) maken het mogelijk vanuit het abonnement de API limieten te verhogen.
Het is voor ons lastig om precies te voorspellen wat het maximale aantal transacties is dat een koppeling goed aankan, omdat het afhangt van
- de webwinkel software
- het boekhoudpakket
- de piek belasting op een uur / dag
- het aantal bestelregels in een order
- instellingen op de koppeling (vb vaste debiteuren)
- welke entiteit in het boekhoudpakket wordt aangemaakt
Een voorbeeld van het laatste. Er zijn best veel klanten die in Exact Online willen boeken op de entiteit 'order', omdat ze ook graag op de artikelen boeken zdd de voorraad in Exact Online actueel gehouden kan worden. Bovendien willen ze graag op de eindklant (debiteur) boeken en liefst op de bestaande eindklant. Voor de koppeling moeten we dan de volgende API calls doen:
- 1 call: bestaat de debiteur? (zo niet, maken we hem aan)
- per bestelregel 1 call: bestaat het artikel? (zo niet, maken we het aan)
- 1 call om de boeking een order aan te maken met debiteur, artikel, prijs en btw
- 1 call om de betaling toe te voegen
Voor klanten die veel orders met veel bestelregels krijgen, is het aantal api-calls van 15 per transactie heel gewoon. Als je dan ook nog eens veels transacties per piekuur of dag hebt, worden de transacties op een gegeven moment geweigerd door het boekhoudpakket, hoe slim we het ook queuen.
Uiteraard proberen we met onze klanten mee te denken hoe de financiële informatie toch naar het boekhoudpakket doorgezet kan worden (vb door verkooptransacties of dagomzet door te zetten), maar daarmee verliest de klant soms gewenste logistieke functionaliteit (vb artikelen of voorraad).
Efficientie. Al onze koppelingen worden regelmatig geëvalueerd met betrekking tot de API limieten zoals de boekhoudpakketten (en de webwinkel systemen!) die opleggen. Onze koppelingen zijn efficient en voldoen doorgaans aan de gestelde technische eisen en limieten. Wij hebben er bewust voor gekozen geen merchant data op ons platform op te slaan (vb de artikelen die een klant in de boekhouding heeft staan). Daarom moeten we echt alle genoemde calls doen en is er een beperking op het aantal transacties dat een koppeling kan doorzetten.
Wat gebeurt er bij het raken van een api limiet? Voor grote klanten kunnen wij niet uitsluiten dat API grenzen periodiek geraakt worden. De koppeling probeert dan op een later moment een eventueel niet doorgezette bestelling zelf alsnog door te zetten en te rapporteren op het dashboard van de koppeling. Voor klanten die af en toe een piek hebben en net de api limiet raken is dit een werkbare oplossing.
Oplossing? Sommige boekhoudpakketen (vb Exact) ken(n)(d)en het concept van een tijdelijke API-limiet verhoging. Omdat dit echt tijdelijk is, adviseren we klanten hier geen gebruik van te maken, want uiteindelijk loopt een koppeling vast en zijn de herstelwerkzaamheden (inclusief snel groeiende backlog) zeer complex, duur en tijdrovend. Meerdere boekhoudpakketten kennen het concept van een API limiet verhoging (vb Exact, Silvasoft, Yuki). Hiervoor dien je als merchant zelf contact op te nemen met je boekhoudpakket leverancier.
Samengevat: tot 50.000 transacties / jaar zou het gewoon goed moeten gaan, maar daarboven kan het afhankelijk van jouw situaties wel eens niet passen. Het kan dan lonen contact op te nemen met je boekhoudpakket om een 'hogere' API limiet af te spreken (tegen vergoeding). In een enkel geval kunnen we je helaas niet helpen.
