Wat is een API-koppeling?

Een API-koppeling klinkt snel als iets voor developers. Toch is het vooral een praktische keuze: wil je handmatig blijven overtypen, een standaardapp gebruiken of iets op maat laten maken?

De beste vraag is niet: kan dit technisch? De betere vraag is: welke gegevens moeten wanneer van systeem A naar systeem B, en wat mag er gebeuren als dat een keer niet lukt?

Stel, je hebt een fictieve webwinkel: voorbeeld.nl. Iemand plaatst een bestelling. Daarna wil je die order in je boekhouding hebben, inclusief klantgegevens, betaling en eventueel een refund.

Dat kan op grofweg drie manieren.

Een kant-en-klare app.
Voor Shopify naar Moneybird bestaat bijvoorbeeld een Shopify-app. Die synchroniseert onder meer Shopify POS-orders, refunds, klantgegevens en Shopify Payments. Het Basic-plan synchroniseert elke 60 minuten. PRO doet dat vrijwel realtime. Dit is vaak de beste keuze als je proces standaard is.

Een eigen API-koppeling.
Moneybird heeft een REST API. Daarmee kan een ontwikkelaar zelf orders, klanten of factuurgegevens ophalen en doorzetten. Maar er zijn grenzen. Kom je boven de throttlinglimiet, dan krijg je HTTP 429 terug. De standaardlimiet is 150 requests per 5 minuten. Voor rapportages is dat 50 requests per 5 minuten.

Een webhook met daarna een API-aanroep.
Een webhook is een melding naar jouw URL. Bijvoorbeeld: er is een order gewijzigd. Daarna haalt je systeem via de API de details op. Dat zie je ook bij Mollie-webhooks: Mollie stuurt alleen een resource-ID naar je webhook-URL. Je server moet daarna via de Mollie API de actuele status ophalen.

Een versimpeld voorbeeld:

app.post("/webhook/order", async (req, res) => {
  res.status(200).send("ok")

  const orderId = req.body.id

  const order = await webshopApi.getOrder(orderId)
  await boekhoudingApi.createInvoice(order)
})

Belangrijk detail: eerst snel reageren, daarna verwerken. Zeker bij webhooks wil je niet dat de verzendende partij denkt dat jouw systeem niet luistert.

Als je dit negeert, krijg je geen technisch probleem. Je krijgt een bedrijfsprobleem.

Orders staan dan wel in je webshop, maar niet in je boekhouding. Refunds worden vergeten. Klantgegevens verschillen per systeem. Of iemand moet alsnog elke week data exporteren, controleren en corrigeren.

Bij kleine aantallen voelt dat misschien nog te doen. Maar handwerk wordt snel rommelig zodra je meer retouren, betaalstatussen of uitzonderingen krijgt. En juist uitzonderingen zijn waar koppelingen vaak hun waarde bewijzen.

Er zit ook een AVG-kant aan. Als een koppeling klant-, order- of factuurgegevens verwerkt, blijven de rollen belangrijk. De Autoriteit Persoonsgegevens maakt onderscheid tussen de verwerkingsverantwoordelijke, die doel en middelen bepaalt, en de verwerker, die persoonsgegevens verwerkt namens die verantwoordelijke. Dat is niet ineens weg omdat er “een API” tussen zit.

Een API-koppeling meteen als maatwerk zien.
Dat is vaak te duur en te kwetsbaar gedacht. Voor standaardstromen, zoals orders van Shopify naar Moneybird, bestaat soms al een app. Begin daar. Pas als die app je proces niet goed ondersteunt, wordt maatwerk logisch.

Denken dat realtime onbeperkt is.
Vrijwel realtime klinkt fijn, maar systemen hebben limieten. Shopify REST Admin API-limieten zijn request-based: standaard 2 requests per seconde, Advanced Shopify 4 requests per seconde, Shopify Plus 20 requests per seconde en Shopify for enterprise 40 requests per seconde. Realtime betekent dus niet dat je onbeperkt mag blijven trekken en duwen.

Webhooks behandelen als volledige data.
Een webhook is meestal een seintje. Geen complete administratie. Bij Mollie krijg je alleen een resource-ID. Bij WooCommerce zijn webhooks bedoeld voor gebeurtenissen zoals order-, product-, coupon- of klantwijzigingen. De payload gebruikt hetzelfde dataformaat als de REST API, maar dat betekent niet dat je nooit meer iets hoeft op te halen.

Geen foutafhandeling maken.
WooCommerce bewaart maximaal 25 webhook-deliverylogs en schakelt een webhook uit na 5 opeenvolgende mislukte afleverpogingen. Shopify HTTPS-webhooks moeten binnen 5 seconden een 200-series response teruggeven. Shopify probeert mislukte webhook-deliveries tot 8 keer opnieuw binnen 4 uur. Als niemand deze signalen controleert, kan je koppeling stil kapotgaan.

• —
  Shopify: let op welke API je gebruikt. Shopify beschouwt de REST Admin API sinds 1 oktober 2024 als legacy. Vanaf 1 april 2025 moeten alle nieuwe public apps uitsluitend de GraphQL Admin API gebruiken. Ook gelden limieten voor arrays: Shopify API-inputarrays mogen maximaal 250 items bevatten.
• —
  WordPress met WooCommerce: REST API-sleutels hebben expliciete rechten: Read, Write of Read/Write. Geef niet meer rechten dan nodig. Let ook op dat de Consumer Secret na het aanmaken maar één keer wordt getoond.
• —
  Next.js: hier bouw je vaak zelf de tussenlaag. Dat geeft vrijheid, maar ook verantwoordelijkheid. Je moet zelf omgaan met API-limieten, webhook-antwoorden, beveiliging en logging.

Mijn beslisregel: kies een kant-en-klare app als de datastroom standaard is, kies een eigen API-koppeling als je regels of velden afwijken, en gebruik webhooks als je op gebeurtenissen wilt reageren.

Wil je breder snappen waar dit onder valt, begin dan bij Automatisering & AI voor MKB-ondernemers. Gaat het om bouwen of laten bouwen, dan past API-koppeling: wat kost het en wat levert het op? beter.