API gateway of directe koppeling: wat past bij uw situatie?

Een webshop die voorraadstanden ophaalt uit het ERP. Een klantportaal dat gegevens uit het CRM laat zien. Een app die betalingen afhandelt. Zolang alles loopt, denkt niemand daarover na. Dat verandert op de dag dat een van die systemen wordt vervangen of een uur uit de lucht is.

De keuze tussen een API gateway en een directe koppeling wordt vaak gepresenteerd als een technische kwestie. Dat is het maar deels. Veel zwaarder weegt wat er gebeurt als een leverancier zijn API aanpast, als er een vijfde applicatie bijkomt, of als iemand om drie uur 's nachts moet uitzoeken waarom bestellingen niet doorkomen.

Een directe koppeling staat er vaak binnen een paar dagen. Een gateway kost meer ontwerptijd vooraf. Dat maakt de eerste optie goedkoper bij de start, maar niet automatisch goedkoper over vijf jaar. Welke route bij u past, hangt af van uw landschap, uw risico's en wat u de komende jaren van plan bent.

Wat is een directe koppeling?

Bij een directe koppeling praat systeem A rechtstreeks met systeem B. Uw webapplicatie vraagt een orderstatus op bij het ERP. Uw CRM duwt nieuwe klantgegevens door naar het marketingplatform. Alle benodigde kennis zit in die koppeling zelf: de logica voor authenticatie, het omzetten van velden, de foutafhandeling en de precieze aanroep die de andere partij verwacht.

Daar is niets mis mee. Voor een afgebakende integratie is het vaak de verstandigste keuze. Een intern systeem dat eenmaal per nacht productdata synchroniseert met één leverancier heeft geen extra laag nodig. De datastroom is voorspelbaar, de interfaces zijn stabiel en er zijn nauwelijks afhankelijkheden. Infrastructuur toevoegen levert dan vooral beheerwerk op.

Het wordt anders zodra dezelfde bron meerdere afnemers heeft. Hangt uw ERP rechtstreeks aan de webshop, het magazijn, een B2B-portaal en een mobiele app, dan kent elk van die vier de technische details van dat ERP. Wijzigt de inlogmethode of de structuur van een veld, dan past u op vier plekken aan en test u op vier plekken. Bij de vierde blijkt dan vaak dat niemand nog weet wie die koppeling ooit heeft gebouwd.

Wanneer een directe koppeling prima werkt

Klein van opzet, een duidelijk doel, weinig verwachte wijzigingen en een handvol systemen: dan hoeft u het niet ingewikkelder te maken. Ook als realtime niet bedrijfskritisch is, kan een eenvoudige nachtelijke synchronisatie betrouwbaarder uitpakken dan een architectuur die niemand helemaal overziet.

Er is wel een voorwaarde: het eigenaarschap moet geregeld zijn. Iemand moet in de gaten houden of de koppeling nog draait, certificaten tijdig vernieuwen, aangekondigde API-wijzigingen beoordelen en fouten oppakken. Een koppeling die na oplevering nooit meer aandacht krijgt, is geen oplossing. Dat is een uitgesteld probleem.

Wat doet een API gateway?

Een gateway zit tussen uw applicaties en de systemen daarachter. In plaats van dat iedere applicatie zelf het ERP, CRM of betaalplatform benadert, praat ze met één gecontroleerd toegangspunt. Dat punt stuurt verzoeken door, controleert wie wat mag en levert gegevens in de vorm die de afnemer verwacht.

Het effect daarvan is heel concreet. Uw klantportaal hoeft niet te weten in welk systeem een factuur staat. Het vraagt factuurgegevens op en krijgt die. Stapt u later over op een ander financieel pakket, dan blijft de interface voor dat portaal in de meeste gevallen gelijk. De verbouwing zit achter de gateway, op één plek, waar u hem kunt testen voordat iemand er iets van merkt.

Daarnaast kunt u authenticatie centraal regelen, verkeer begrenzen, logging bij elkaar brengen en twee versies van een API tijdelijk naast elkaar laten bestaan. Dat laatste is goud waard zodra externe partners op uw API zijn aangesloten, want u kunt niet iedereen dwingen om op dezelfde dag over te stappen.

Een gateway lost ondertussen niets automatisch op. Ook hier beslist u zelf wat er gebeurt bij time-outs, wat u cachet, wie welke rechten krijgt en waarop u gealarmeerd wilt worden. Een slecht ontworpen gateway is gewoon een nieuw knelpunt, met als verzwaring dat al uw verkeer er doorheen loopt. De winst zit in bewust centraliseren waar dat iets oplevert, niet in alles achter één laag duwen omdat het netter staat op een architectuurplaat.

Waar de afweging werkelijk over gaat

De vraag is niet welke aanpak moderner is. De vraag is waar u verandering, groei of risico verwacht. Een directe koppeling is geoptimaliseerd voor snelheid en eenvoud nu. Een gateway is geoptimaliseerd voor controle zodra het landschap groter en rommeliger wordt. Beide kunnen het juiste antwoord zijn, ze horen alleen bij verschillende situaties.

Hoe stabiel is wat erachter zit?

Staat er een nieuw CRM, ERP of PIM op de rol? Werkt u met leveranciers die hun API een paar keer per jaar aanpassen? Dan voorkomt een gateway dat elke afnemende applicatie afzonderlijk mee moet verhuizen. U houdt uw eigen processen gescheiden van de eigenaardigheden van een specifiek pakket.

Is het achterliggende systeem juist al jaren hetzelfde en staat vervanging niet op de agenda, dan is een directe koppeling de nuchtere keuze. Bouw geen abstractielaag voor een probleem dat waarschijnlijk nooit langskomt.

Hoeveel afnemers krijgt u erbij?

Eén applicatie die met één externe dienst praat, vraagt niet om een gateway. Zodra meerdere websites, apps, interne tools, dealers of partners toegang nodig hebben, kantelt dat. U wilt dan niet per toepassing losse sleutels, rechten en uitzonderingen bijhouden in een spreadsheet die maar één collega nog begrijpt.

Dat geldt extra voor organisaties die groeien via overnames of nieuwe verkoopkanalen. Wat vandaag een los B2B-portaal is, is over twee jaar misschien onderdeel van een breder platform. Een gateway geeft u dan een vaste manier om systemen toe te voegen zonder bestaande toepassingen open te breken.

Beveiliging en continuïteit

Een rechtstreekse koppeling kan veilig zijn, mits goed ingericht. Maar met elke koppeling erbij groeit de kans dat sleutels, permissies en beveiligingsregels verspreid raken over plekken waar niemand meer kijkt. Met een gateway regelt u toegangscontrole, tokenbeheer en snelheidslimieten op één plek, en ziet u in één overzicht wie waar binnenkomt.

Continuïteit weegt minstens zo zwaar. Wat moet er gebeuren als een externe API tien seconden over een antwoord doet? Wacht uw hele webshop, of toont u even een waarde uit cache? Moet een bestelling meteen falen, of mag die in een wachtrij staan tot de dienst weer bereikbaar is? Die keuzes hoort u te maken, welke route u ook neemt. Een gateway maakt het alleen makkelijker om ze overal hetzelfde toe te passen in plaats van per koppeling opnieuw te bedenken.

Snelheid en kosten

Een extra laag kost extra verwerking. Bij tijdkritische toepassingen, zoals bepaalde transacties of communicatie met machines op een productielijn, moet u meten of een gateway binnen uw responstijd blijft. Soms is het antwoord nee en is een directe, goed beveiligde verbinding technisch de betere keuze. Meten helpt daarbij meer dan aannemen, want de vertraging van een gateway valt in de praktijk vaak mee en de netwerkroute eronder bepaalt veel meer.

Kijk tegelijk verder dan milliseconden. De grootste kostenpost zit zelden in infrastructuur. Die zit in incidenten, dubbel werk en wijzigingen die u met drie leveranciers moet afstemmen. Als een storing pas na vier uur duidelijk wordt omdat de logging over vier systemen is verdeeld, hebt u een goed beheerde gateway allang terugverdiend.

Kies per datastroom, niet vanuit een principe

De meest gemaakte fout is om één principe te kiezen voor alle integraties. Een hybride aanpak is vaker logisch: een eenvoudige interne synchronisatie loopt direct, terwijl klantgerichte API's en partnerintegraties via de gateway gaan.

Breng daarom eerst uw datastromen in kaart. Welke gegevens zijn bedrijfskritisch? Welke processen moeten echt realtime werken en welke lijken dat alleen? Waar gaan persoonsgegevens of betalingen over de lijn? Welke systemen kunnen binnen twee jaar veranderen? En wie wordt gebeld als een koppeling stilvalt?

Met die antwoorden op papier is de keuze per stroom meestal niet moeilijk meer. Soms is dat een directe REST-koppeling met degelijke monitoring. Soms een gateway met versiebeheer en centrale autorisatie. En soms is asynchrone verwerking met een wachtrij het juiste antwoord, omdat uw proces niet mag stilvallen door een externe partij die even niet bereikbaar is.

Voorkom dat uw integraties een black box worden

Welke architectuur u kiest, maakt minder uit dan hoe u hem beheert. Leg vast welke systemen gegevens uitwisselen, welke bron per veld leidend is, wat er gebeurt bij fouten en wie toegang heeft. Zorg voor meldingen die afgaan voordat de eerste klant belt. Dat klinkt saai, maar het is het verschil tussen een vervelend halfuur en een dag brandjes blussen.

Test wijzigingen daarnaast altijd eerst buiten productie. Een update van een externe API, een vervangen certificaat of een aangepaste firewallregel kan uw koppeling slopen zonder dat er één regel in uw eigen software is veranderd. Met een testomgeving, duidelijke logging en een vast aanspreekpunt blijven zulke verrassingen beheersbaar.

Voor organisaties die afhankelijk zijn van hun digitale processen is de beste keuze dus zelden de architectuur die op papier het fraaist is. Het is de keuze die past bij de impact op uw bedrijf en die u over twee jaar nog snel kunt beheren, aanpassen en herstellen. Daar begint LJPc ook: niet met een standaardoplossing, maar met de vraag waar uw processen echt niet mogen haperen.