Connector

Wat is een connector?

Een connector is kant-en-klare software die met één specifiek systeem praat, zodat jij dat gesprek niet zelf moet schrijven. Je richt de HubSpot-connector van Fivetran op je CRM, geeft toestemming, en je contacten, deals en bedrijven beginnen in je warehouse te landen. De HTTP-calls eronder krijg je nooit te zien, en dat is de bedoeling.

Het woord dekt twee dingen. In een datatool leest een connector een bron of schrijft hij naar een bestemming. In een automatiseringsplatform is het het blokje dat je in een flow sleept: Microsoft beschrijft een Power Platform-connector als datgene waarmee de onderliggende dienst kan praten met Power Automate, Power Apps, Logic Apps en Copilot Studio, via acties zoals een bestand aanmaken en triggers zoals wanneer er een nieuw item bijkomt.

Veel mensen halen de connector en de API door elkaar. De API is de deur die de leverancier openzet. De connector is de software die weet hoe ze daar elke vijftien minuten door moet, drie jaar aan een stuk, terwijl er niemand naar kijkt.

Wat een connector bij elke run doet

De takenlijst is kort, geen enkel onderdeel is spectaculair, en net daarom haalt kopen het meestal van zelf schrijven.

• Aanmelden. Inloggen met OAuth of een API-sleutel, en het token vernieuwen voor het vervalt, zonder dat er iemand bij zit.

• Het schema ontdekken. Aan de bron vragen welke objecten en velden er vandaag bestaan, in plaats van de indeling van vorig jaar te veronderstellen.

• Alleen lezen wat veranderd is. Airbyte omschrijft het cursorveld als de kolom waarin de cursor staat, meestal iets als updated_at. Elke run vraagt de rijen op die boven de hoogste waarde van de vorige run liggen, en de eerste run heeft nog geen cursor en leest dus alles.

• Door de pagina's lopen. Records per pagina opvragen en blijven doorvragen tot de bron zegt dat er niets meer is.

• Onder de rate limit blijven. HubSpot laat een private app op een Professional-account 190 verzoeken per 10 seconden toe, en het dagbudget van 625.000 verzoeken deel je met elke andere private app op datzelfde account.

• Types vertalen. Een tekst uit JSON wordt een datum, een getal wordt een decimaal met de juiste precisie, en er moet iets gebeuren zodra de bron een andere vorm begint te sturen.

• Zijn stand noteren. Bijhouden tot welke cursorwaarde hij geraakt is, zodat een mislukte run iets is dat je hervat en niet iets dat je opnieuw begint.

Elk stuk apart is niet moeilijk. Alles samen, onbewaakt draaiend, vormt het grootste deel van wat een koppeling echt kost. Een REST-call die je in tien minuten schrijft, is niet hetzelfde als software die een hernoemd veld, een vervallen token en een 429 om drie uur 's nachts overleeft, en je daarna nog vertelt welke van de drie het was.

Source-, destination- en actieconnectoren

Source-connectoren lezen. Ze halen data uit je CRM, je boekhoudpakket, een databank of een bestandsopslag en geven rijen door aan de pijplijn. Alles hierboven over cursors, paginering en stand hoort bij deze vorm.

Destination-connectoren schrijven. Ze laden die rijen in een warehouse of lakehouse, maken de tabellen aan, doen een upsert op een primaire sleutel en bepalen hoe een verwijdering in de bron eruitziet. Fivetran heeft daar drie antwoorden op: soft delete mode zet een vlagje op de rij, live mode houdt een exacte kopie van de brontabel bij, en history mode bewaart elke versie van de rij.

Actieconnectoren in een automatiseringsplatform doen geen van beide in bulk. Ze vuren een trigger af of voeren één handeling uit: een bestand aanmaken, een bericht sturen, een klant opzoeken. Een flow roept er soms vijf na elkaar aan, één keer per gebeurtenis, en geen enkele houdt een cursor bij.

Lees het getal op de website van een leverancier dus met de nodige argwaan. Een platform met 300 source-connectoren en een platform met 1.000 actieconnectoren tellen niet hetzelfde, en geen van beide getallen zegt of net jouw twee systemen deftig gedekt zijn.

Een onderhouden connector tegenover je eigen API-script

Allebei lezen ze dezelfde API en zetten ze dezelfde rijen neer. Ze verschillen op één punt: wie het werk doet op de dag dat de leverancier iets wijzigt.

Bij je eigen script ben jij dat. Een veld krijgt een andere naam, een parameter wordt verplicht, de manier van pagineren verandert, de OAuth-scopes worden aangescherpt. Het script werkt tot het niet meer werkt, en de collega die het schreef, werkt hier al twee jobs niet meer.

Bij een onderhouden connector is het de taak van de leverancier. Airbyte schrijft dat verschil letterlijk in zijn supportniveaus. Zijn eigen connectoren krijgen weinig breaking changes en een venster om te upgraden. Marketplace-connectoren komen van mensen uit de community, zonder support en zonder SLA, en kunnen zonder waarschuwing achterwaarts incompatibel worden. Een connector die je zelf bouwt, komt met geen enkele garantie dat hij productieklaar is.

Microsoft trekt de lijn per uitgever. Een verified publisher is zelf eigenaar van de dienst achter de connector, een independent publisher niet: eender wie mag een connector indienen voor een dienst die hij gebruikt. Allebei passeren ze dezelfde review, dus wat verschilt is wie je kan aanspreken als de dienst eronder verschuift.

Voor een KMO is de vuistregel kort. Koop voor de systemen die iedereen draait: je CRM, je boekhouding, je webshop, je advertentieplatformen. Bouw alleen waar je bron echt afwijkend is, of waar de onderhouden connector niet ver genoeg gaat. Bouwen is het korte stuk, eigenaar zijn duurt zolang je de bron gebruikt.

Wat je nakijkt voor je op een connector rekent

Connectoren zijn niet inwisselbaar, en de verschillen komen pas boven zodra je ervan afhangt. Zes vragen, ongeveer in de volgorde waarin ze je pakken.

1. Welke objecten en velden dekt hij? Een connector dekt zelden de volledige API. Leg zijn gedocumenteerde tabellenlijst naast de objecten die je rapporten nodig hebben.

2. Leest hij incrementeel, en op welke kolom? Airbyte benoemt zelf hoe het misloopt: veranderen records zonder dat het cursorveld mee bijgewerkt wordt, dan pikt de sync die aanpassingen niet op. Een bulkupdate die rechtstreeks op de brondatabank draait, blijft voorgoed onzichtbaar.

3. Hoe gaat hij om met verwijderingen? Een verwijderd record kan in de bestemming ook verdwijnen, een vlagje krijgen, of daar voor altijd blijven staan. Airbyte geeft verwijderingen alleen door als de bron ze meestuurt, en in de praktijk betekent dat change data capture.

4. Wat gebeurt er met custom velden? Custom properties en custom objecten worden vaak anders behandeld dan de standaardvelden, en daar stellen CRM-connectoren het vaakst teleur.

5. Hoe ver gaat de eerste lading terug? Verschillende CRM-connectoren beperken de eerste lading tot een historisch venster dat je in maanden instelt, in plaats van alles op te halen. Zet dat op twaalf, en de driejarentrend die de directie in januari wil, is een probleem dat je in januari ontdekt.

6. Wat doet hij als de leverancier de API wijzigt? Airbyte controleert het bronschema voor elke sync, behandelt nieuwe en verwijderde kolommen als niet-brekend, en pauzeert de verbinding voor menselijke controle zodra de primaire sleutel of de cursor uit de bron verdwijnt. Fivetran werkt met drie instellingen: alle nieuwe data toelaten, enkel nieuwe kolommen toelaten, of alles blokkeren. Geen enkele standaard klopt voor iedereen, en iemand moet kiezen.

Een uitgewerkt voorbeeld: de CRM-connector en het custom veld

Een groothandel draait op HubSpot. Verkoop heeft custom properties aan deals toegevoegd, en achttien maanden lang splitst het maandrapport de gewonnen omzet op per leadbron. Dan hernoemt iemand in juni de property van "Leadbron" naar "Acquisitiekanaal". In HubSpot zelf breekt er niets, de historische waarden staan er nog onder het nieuwe label. In het warehouse ziet de connector een nieuwe kolom. Een hernoemd custom veld zet doorgaans geen nieuwe lezing van de historiek in gang, dus die kolom vult zich pas vanaf de hernoeming en je moet zelf een historische sync starten om de rest bij te werken.

Het rapport blijft dus gewoon draaien, met een kanaal bij elke deal vanaf juni en niets daarvoor, en nergens een foutmelding. De eerste lezing is "we hebben veel minder toegewezen deals dan vorig jaar", de tweede is "marketing is gestopt met leads te taggen", en het echte antwoord kost iemand een namiddag en een blik op twee kolommen. Zo ziet die kost er dus uit. Er gaat geen pijplijn stuk, er valt een stil gat in een cijfer waar mensen al op rekenden.

Connectoren voor AI-agents

Diezelfde discussie loopt nu een verdieping hoger. Een agent die aan jouw systemen moet, botst op het probleem waar integratieplatformen tien jaar geleden op botsten: elk systeem heeft een eigen API, een eigen manier van aanmelden en een eigen woordenschat, en per systeem per agent een aparte brug schrijven schaalt niet.

Het Model Context Protocol is de poging tot standaardisatie, en het leent het woord om dezelfde reden. De specificatie noemt de client een connector binnen de hostapplicatie, en haalt haar inspiratie bij het Language Server Protocol, dat voor editors en programmeertalen deed wat MCP voor AI-applicaties en tools probeert te doen.

Een data-MCP-server is de agentkant van een source-connector: hij staat voor een databank of een bedrijfsapplicatie, meldt zich één keer aan, houdt de aanroeper weg van de ruwe inloggegevens, en geeft het model een korte lijst tools in plaats van een connectiestring. Wat verandert, is hoe het misloopt. Een warehouse-connector die rijen mist, laat een gat achter dat je met tellen vindt. Een agent die rijen mist, geeft iemand een overtuigd antwoord met dat gat er al in.