Software koppelen: ook als er geen API is

Software koppelen betekent dat gegevens zelf van het ene systeem naar het andere gaan. Een bestelling uit je webshop komt in je boekhouding, een klant uit je formulier komt in je CRM, en niemand hoeft iets over te typen.

De meeste uitleg stopt bij de API. Logisch, want dat is de netste route. Maar in het MKB draait veel op software zonder API: een oud kassasysteem, een branchepakket, het portaal van een leverancier. Dan is koppelen nog steeds mogelijk. Je moet alleen weten welke route je hebt en wat er bij die route misgaat.

Er zijn grofweg zeven routes. Hoe hoger op de ladder, hoe steviger de koppeling en hoe minder onderhoud. Hoe lager, hoe meer controle je zelf moet inbouwen.

Bovenaan staat de kant-en-klare app, niet de API. Bestaat er een app die precies doet wat je nodig hebt, dan onderhoudt de maker hem en hoef jij niets te bouwen. Een eigen API-koppeling is pas logisch als je proces afwijkt. Hoe dat werkt, lees je in wat een API-koppeling is.

Beslisregel: kies altijd de hoogste route die je systeem toelaat. Lager op de ladder gaan is geen schande, maar wel een keuze voor meer controlewerk.

Je hoeft de techniek niet te kennen om te kiezen. Loop deze vragen van boven naar beneden af en stop bij de eerste "ja".

De vragen kun je meestal zelf beantwoorden. Kijk in de instellingen van je pakket naar "koppelingen", "apps", "API" of "export". Vind je niets, mail dan de leverancier met één vraag: "Hoe krijg ik mijn orders (of klanten, of voorraad) automatisch uit jullie systeem?" Het antwoord vertelt je meteen op welke trede je staat.

Kan je systeem een export maken, dan heb je een koppeling. Het ene systeem zet elke nacht of elk uur een bestand klaar, een script of een tool als n8n pakt het op en zet de regels door. Veel groothandels werken zo voor prijzen en voorraad, via een SFTP-server. n8n heeft daar een standaardblok voor dat bestanden van een FTP- of SFTP-server kan ophalen.

Het klinkt ouderwets, maar het werkt goed. Op één voorwaarde: je bouwt de controle zelf in. Een API geeft een foutmelding als er iets mis is. Een bestand niet. Dat staat er gewoon, half of dubbel.

Waar het in de praktijk misgaat:

• —
  Er is geen echte standaard. CSV lijkt simpel, maar zelfs de bekendste beschrijving, RFC 4180, zegt dat het formaat nooit formeel is vastgelegd. Een komma of een puntkomma, aanhalingstekens of niet: elk pakket doet het net anders. In Nederland gebruikt Excel vaak een puntkomma.
• —
  Iemand voegt een kolom toe. De leverancier past de export aan, en je koppeling leest ineens de prijs uit de kolom voor de omschrijving. Controleer daarom de kolomkoppen bij elk bestand.
• —
  Hetzelfde bestand twee keer. Een export die opnieuw wordt gedraaid, levert dubbele orders op. Houd bij welke bestanden of regels al verwerkt zijn.
• —
  Half geschreven bestanden. Pak je een bestand op terwijl het nog wordt weggeschreven, dan mis je de laatste regels. Laat de afzender een vaste naam of een apart "klaar"-bestand gebruiken.

Beslisregel: een bestandskoppeling is prima, zolang er een controlestap tussen zit die stopt en meldt in plaats van gokt.

Een feed is een vast adres waar een systeem actuele gegevens neerzet, meestal als XML of JSON. Denk aan het assortiment van een leverancier of de productfeed die je naar Google Shopping stuurt. Je haalt hem op zo vaak als je wilt, en verwerkt wat er veranderd is.

Een voorbeeld uit de praktijk: een webshopplatform voor bakkers dat ik bekeek, biedt een openbare XML-feed met het assortiment, prijzen en bestelregels per product. Daarmee kun je prima een eigen, snellere winkelpagina bouwen. Maar bestellen gaat niet via die feed. Daarvoor stuurt het platform je terug naar zijn eigen winkelwagen. Dat is typisch voor feeds: lezen kan, schrijven niet.

Let ook op wat er in de feed staat. In hetzelfde voorbeeld stonden allergenen alleen als losse tekst in de omschrijving, niet als aparte velden. Een feed is nooit beter dan de gegevens die erin worden ingevoerd.

Beslisregel: gebruik een feed om gegevens op te halen en te tonen, nooit als enige bron voor iets dat terug moet naar het systeem.

Draait je pakket op een eigen server of in je kantoor, dan staan de gegevens in een database. Die kun je soms direct uitlezen. Het is snel en volledig, maar het is ook de route waarbij je het meest afhankelijk bent van iets dat niet voor jou bedoeld is.

Bij een update kan de leverancier tabellen hernoemen of velden verplaatsen, zonder dat aan te kondigen. Je koppeling breekt dan stil. Schrijven in die database is nog riskanter: je omzeilt alle controles van het pakket, en daarmee vaak ook je supportafspraken.

Beslisregel: lees alleen, met een apart account met leesrechten, en alleen als de leverancier ermee akkoord is.

Komen bestellingen, aanvragen of meldingen al per e-mail binnen, dan kun je die mails automatisch laten verwerken. n8n heeft bijvoorbeeld een standaardtrigger die een mailbox via IMAP leest. Werkt een vast formulier of systeem de mail op, dan staat de informatie meestal steeds op dezelfde plek en is het goed uit te lezen.

Het wordt lastig zodra mensen de mail schrijven. Een klant die "doe maar 2 bossche bollen en morgen ophalen" stuurt, is geen vast formaat. Dat kun je deels met AI uitlezen, maar zet dan altijd een mens tussen voor het daadwerkelijk boeken.

Beslisregel: mail uitlezen werkt als de afzender een systeem is. Schrijft een mens de mail, laat de koppeling dan een voorstel klaarzetten, geen definitieve order.

Heeft een systeem niets van het bovenstaande, dan kun je een robot het werk laten doen dat een medewerker nu doet: inloggen, klikken, gegevens overnemen. Dat heet RPA. Tools als Power Automate voor desktop en UiPath zijn daarvoor gemaakt. Op een website heet hetzelfde scraping.

Het werkt, tot het scherm verandert. Een nieuwe knop, een cookiemelding of een gewijzigde inlogpagina, en de robot klikt ernaast. Er zit ook een juridische kant aan. Gaat het om persoonsgegevens, dan is de Autoriteit Persoonsgegevens duidelijk: volgens de AP is scraping door bedrijven bijna altijd in strijd met de AVG. En ook zonder persoonsgegevens kan het tegen de voorwaarden van de site ingaan.

Beslisregel: RPA of scraping alleen als tijdelijke brug, met monitoring die je waarschuwt zodra de robot vastloopt.

Hoe hoger op de ladder, hoe meer het systeem zelf regelt. Maar een paar dingen moet je altijd zelf inrichten:

• —
  Een melding als het misgaat. Koppelingen gaan zelden met een knal kapot. Ze stoppen stil. WooCommerce zet een webhook bijvoorbeeld uit na 5 mislukte afleverpogingen. Zonder melding merk je dat pas als je boekhouding niet klopt.
• —
  Eén plek waar de waarheid staat. Spreek af welk systeem leidend is voor klanten, prijzen of voorraad. Anders overschrijven twee systemen elkaar.
• —
  Iemand die verantwoordelijk is. Een koppeling is geen project dat af is. Pakketten krijgen updates, exports veranderen, wachtwoorden verlopen.
• —
  Een verwerkersovereenkomst als er persoonsgegevens door een externe tool gaan, zoals een automatiseringsplatform in de cloud.

Wil je weten welke tool je gebruikt voor de stappen tussen de systemen, lees dan n8n, Make of Zapier kiezen. Wil je weten wat een koppeling kost en oplevert, dan helpt API-koppeling: wat kost het en wat levert het op?.

Beslisregel: een koppeling zonder melding bij fouten is geen koppeling, maar een risico dat je later pas ziet.