Wat is een API? De afspraak waarmee software met andere software praat. Waarom een goede API de voorwaarde is voor automatisering en koppelingen.
Een API is de afspraak waarmee het ene programma gegevens of handelingen opvraagt bij het andere, zonder te weten hoe dat er van binnen uitziet. Je vraagt om een klant, een factuur of een berekening en krijgt een antwoord in een vastgelegde vorm. Zonder die afspraak praat software langs elkaar heen.
Stel je een balie voor: je vraagt om iets, je krijgt het, en je hoeft niet te weten waar het in het magazijn ligt. Een API werkt zo, maar dan tussen programma's. Je pakket met afspraken kan via een API worden gevraagd om de agenda van volgende week; die agenda komt terug in een vast formaat, en het vraagende programma hoeft niet te snappen hoe de agenda intern wordt opgeslagen.
De kracht zit in de afspraak zelf. Er staat in welke vragen je mag stellen, welke gegevens je meesturen moet en wat er terugkomt. Daardoor kan software van verschillende makers samenwerken: je planningstool, je boekhoudpakket en je site praten allemaal dezelfde taal zodra er een API tussen zit. Dat is ook de reden dat API's de voorwaarde zijn voor automatisering: een agent of koppeling kan alleen werken met een systeem dat zich laat bevragen.
Let op het verschil tussen een API die er is en een API die goed is. Sommige pakketten bieden wel een interface, maar zonder de gegevens die jij nodig hebt, of met limieten die een dagelijkse sync bemoeilijken. Dat hoor je pas als je de documentatie leest met jouw eigen vraag erbij. In de discovery van een traject doen we dat bewust, vóór er gebouwd wordt.
De moeite waard is een API altijd als hij er eenmaal staat: hij is de kortste route tussen twee systemen. Belangrijker is de vraag of het pakket aan de andere kant een bruikbare interface heeft. Heeft hij die, dan is een koppeling een kwestie van bouwen. Heeft hij die niet, dan blijven er twee eerlijke opties over: exporteren en importeren via bestanden, of het werk handmatig laten.
Het loont niet om rond een ontbrekende API een omweg te bouwen met schermaflezen of ongedocumenteerde backdoors. Dat soort oplossingen breekt stilletjes zodra de maker iets wijzigt, en niemand ziet het aankomen. Bij software zonder interface is een nette import-export vaak robuuster dan een brute omweg. Minder glimmend, wel voorspelbaar.
We bouwen API's op twee kanten van het werk: als verbindingsstuk tussen jouw bestaande pakketten, en als eigen interface van maatwerksoftware die we leveren zodat die later uitbreidbaar blijft. In de discovery lezen we per systeem de documentatie en toetsen of de gegevens die jij nodig hebt er werkelijk in zitten. Offertes lopen via nacalculatie op de echte scope, zonder pakketten of prijslijsten.
De API is de taal, de koppeling is het gesprek dat jij ermee voert. Een API is de interface die een softwarepakket aanbiedt: welke vragen je mag stellen en wat er terugkomt. Een koppeling is het stuk bouwwerk dat die interface gebruikt om twee specifieke systemen met elkaar te laten samenwerken. Er kan dus een koppeling tussen je CRM en je facturatie lopen, met aan weerszijden een API als taal.
De vlotste check staat in de documentatie of het supportcentrum van de leverancier: zoek naar ontwikkelaarsdocumentatie of het woord API in de instellingen. Vraag anders bij de leverancier zelf of je gegevens zoals klanten, afspraken of facturen van buitenaf opgevraagd en aangepast kunnen worden. Let daarbij op de exacte gegevens die jij nodig hebt, want een interface die bestaat maar jouw kernvragen niet beantwoordt, is voor jouw automatisering waardeloos.
Beperkt, en dat moet je niet forceren. Zonder interface blijft er schermaflezen of slepen-en-neerzetten na doen, en dat breekt zodra één knop verplaatst. Voor oudere pakketten zonder interface is een nette omweg vaak beter: periodiek exporteren naar een bestand en dat laten verwerken. Dat is langzamer dan een directe verbinding, maar wel voorspelbaar en te controleren. In de discovery wegen we per systeem af wat passend is.
Een moderne API verkeert via een beveiligde verbinding en vereist authenticatie: alleen wie zich mag authenticeren, komt erin. De echte vraag is wie jij toegang geeft en met welke rechten. Een alleen-lezen sleutel voor rapportages vraagt anders om voorzichtigheid dan een sleutel die mag schrijven. We leggen per koppeling vast welke gegevens eroverheen gaan, hoe lang ze bewaard worden en wie er bij kan, vóór de eerste byte stroomt.
EIGHTY8