API gateway of directe koppeling: wat past bij jouw 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 jou past, hangt af van je landschap, je risico's en wat je de komende jaren van plan bent.

Wat is een directe koppeling?

Bij een directe koppeling praat systeem A rechtstreeks met systeem B. Je webapplicatie vraagt een orderstatus op bij het ERP. Je 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 je 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 pas je op vier plekken aan en test je 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 hoef je 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 je 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. Je klantportaal hoeft niet te weten in welk systeem een factuur staat. Het vraagt factuurgegevens op en krijgt die. Stap je 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 je hem kunt testen voordat iemand er iets van merkt.

Daarnaast kun je 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 je API zijn aangesloten, want je kunt niet iedereen dwingen om op dezelfde dag over te stappen.

Een gateway lost ondertussen niets automatisch op. Ook hier beslis je zelf wat er gebeurt bij time-outs, wat je cachet, wie welke rechten krijgt en waarop je gealarmeerd wilt worden. Een slecht ontworpen gateway is gewoon een nieuw knelpunt, met als verzwaring dat al je 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 je 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? Werk je met leveranciers die hun API een paar keer per jaar aanpassen? Dan voorkomt een gateway dat elke afnemende applicatie afzonderlijk mee moet verhuizen. Je houdt je 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 krijg je 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. Je 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 je 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 regel je toegangscontrole, tokenbeheer en snelheidslimieten op één plek, en zie je 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 jouw hele webshop, of toon je 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 hoor je te maken, welke route je 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 je meten of een gateway binnen je 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 je met drie leveranciers moet afstemmen. Als een storing pas na vier uur duidelijk wordt omdat de logging over vier systemen is verdeeld, heb je 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 je 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 je proces niet mag stilvallen door een externe partij die even niet bereikbaar is.

Voorkom dat je integraties een black box worden

Welke architectuur je kiest, maakt minder uit dan hoe je 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 je koppeling slopen zonder dat er één regel in je 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 je bedrijf en die je over twee jaar nog snel kunt beheren, aanpassen en herstellen. Daar begint LJPc ook: niet met een standaardoplossing, maar met de vraag waar je processen echt niet mogen haperen.