Make.com koppeling maken: zo verbind je je systemen

Wat is een Make.com koppeling eigenlijk?

Met een koppeling bedoelen we hier: gegevens gaan automatisch van het ene systeem naar het andere, zonder dat iemand ze overtypt. Een nieuwe klant in je CRM komt vanzelf in je boekhouding, een ingevuld formulier wordt een taak, een betaalde order wordt een factuur.

In Make bouw je zo'n koppeling als een scenario: een reeks modules die start met een trigger. Het verschil met een "echte" maatwerkkoppeling is dat je niet zelf code schrijft en host. Make regelt het draaien, het inloggen bij de systemen en de logboeken. Jij bepaalt wat er gebeurt.

Dat maakt Make geschikt voor de meeste koppelingen in het mkb: een paar systemen, honderden tot duizenden records per dag, en processen die je goed kunt beschrijven. Een overzicht van scenario's die vaak terugkomen vind je in Make.com workflows voor het mkb. In dit artikel gaat het om de stap daarvoor: hoe je de verbinding met een systeem überhaupt legt.

Welke route kies je: app, HTTP-module of webhook?

Per systeem dat je wilt koppelen kies je een van drie routes. Vaak gebruik je er in één scenario meerdere door elkaar.

1. Een kant-en-klare app in Make

Voor veel bekende pakketten heeft Make een eigen app met modules als "zoek een contact", "maak een factuur" of "let op nieuwe orders". Je logt één keer in, en daarna kies je velden uit een lijst. Dit is de snelste en meest onderhoudsvriendelijke route. Kijk wel goed welke modules er zijn: een app biedt niet altijd alles wat het pakket zelf kan.

2. De HTTP-module en de API van het pakket

Heeft een pakket geen app in Make, of mist de app net de functie die je nodig hebt, dan praat je rechtstreeks met de API van dat pakket. Dat doe je met de module Make a request uit de HTTP-app. Volgens de documentatie van Make (geraadpleegd op 23 oktober 2026) ondersteunt die module de gangbare methodes (GET, POST, PUT, PATCH, DELETE), kan hij zelf door pagina's met resultaten bladeren, en kun je inloggen met een API-sleutel, gebruikersnaam en wachtwoord of OAuth 2.0. Sleutels bewaar je daarbij in de keychain van Make, niet als losse tekst in de module.

Deze route vraagt meer kennis: je moet de API-documentatie van het pakket kunnen lezen en weten hoe het antwoord eruitziet. Maar je kunt dan alles gebruiken wat de API aanbiedt.

3. Een webhook

Een webhook draait de richting om. In plaats van dat Make steeds vraagt "is er iets nieuws?", stuurt het andere systeem zelf een seintje naar een adres in Make zodra er iets gebeurt. Je maakt zo'n adres aan met de module Custom webhook. Het scenario start dan direct, en alleen als er echt iets is. Dat scheelt credits en wachttijd.

Een webhook kan alleen als het bronsysteem webhooks kan versturen. Webformulieren en webshops kunnen dat vaak; sommige boekhoud- en CRM-pakketten niet, of alleen voor bepaalde gebeurtenissen.

Hoe kies je de juiste route per systeem?

Een eenvoudige volgorde die in de praktijk goed werkt:

1. Is er een app in Make met de modules die je nodig hebt? Gebruik die.
2. Kan het bronsysteem een webhook sturen bij de gebeurtenis die je wilt volgen? Gebruik die als trigger, ook als je daarna met app-modules verder werkt.
3. Geen van beide? Gebruik de HTTP-module met de API van het pakket, eventueel als geplande trigger die op een vast interval kijkt wat er nieuw is.

Heeft een pakket helemaal geen API, dan houdt het in Make vaak op. Soms is een export naar een gedeelde map of een mailbox dan de enige uitweg, en die kun je weer met Make oppakken. Dat werkt, maar is kwetsbaarder. Welke pakketten we vaak koppelen, zie je op onze pagina met koppelingen.

Hoe zorg je dat de juiste gegevens bij elkaar komen?

De meeste problemen met koppelingen zitten niet in de techniek, maar in de vertaling tussen twee systemen. Drie dingen leg je vooraf vast:

• Een vaste sleutel. Waarop herken je dat een klant in systeem A dezelfde is als in systeem B? Een e-mailadres, een KvK-nummer of een klantnummer dat je in beide systemen opslaat. Zonder vaste sleutel maakt een koppeling vroeg of laat dubbele records.
• Eén bron per gegeven. Bepaal per veld welk systeem leidend is. Als beide systemen elkaar bijwerken, krijg je een pingpongspel van wijzigingen.
• Een veldenlijst. Een simpele tabel: veld in systeem A, veld in systeem B, en wat er onderweg verandert. Denk aan datumnotaties, btw-codes, landcodes en keuzelijsten die in het ene pakket anders heten dan in het andere.

Die veldenlijst is ook je documentatie. Als over een jaar iemand anders de koppeling moet aanpassen, is dat het eerste wat hij nodig heeft.

Stappenplan: een Make.com koppeling in zes stappen

Een fictief voorbeeld om het concreet te maken. Een installatiebedrijf met twintig medewerkers krijgt aanvragen binnen via een formulier op de website. Een collega typt die over in het CRM en maakt er een taak van voor de planner. Dat willen ze koppelen.

1. Beschrijf de gebeurtenis en de uitkomst. Gebeurtenis: een ingevuld formulier. Uitkomst: een relatie in het CRM (nieuw of bestaand) met een taak voor de planner.
2. Kies per systeem de route. Het formulier kan een webhook sturen, dus dat wordt de trigger. Het CRM heeft een app in Make met modules om te zoeken, aan te maken en een taak toe te voegen.
3. Regel de toegang. Maak in Make een connectie met het CRM, bij voorkeur met een eigen gebruiker of API-sleutel voor koppelingen, niet met het account van een collega. Gaat die collega weg, dan blijft de koppeling werken.
4. Bouw de velden en de sleutel. Zoek eerst op e-mailadres of de relatie al bestaat. Zo ja: koppel de taak aan die relatie. Zo nee: maak hem aan. Zet de velden uit je veldenlijst op hun plek.
5. Test met echte voorbeelden. Een nieuwe klant, een bestaande klant, een formulier met een typfout in het e-mailadres, een formulier zonder telefoonnummer. Kijk per test wat er in het CRM terechtkomt.
6. Regel foutafhandeling en eigenaar. Lukt een stap niet, dan krijgt de collega die het nu doet een mail met de gegevens van het formulier. En er staat één naam bij de koppeling: wie kijkt ernaar als er iets misgaat?

Werk je met Cirqll als CRM, dan staat een vergelijkbaar scenario uitgewerkt in Cirqll en Make.com: 5 automatiseringen.

Waar gaat een Make.com koppeling meestal mis?

Een paar valkuilen die we vaak zien, met wat Make er zelf over zegt in zijn documentatie (geraadpleegd op 23 oktober 2026):

• De connectie verloopt of verliest rechten. Een wachtwoord wordt gewijzigd, een gebruiker uitgeschakeld of een API-sleutel ingetrokken. De koppeling faalt dan bij de eerste run. Gebruik daarom een vaste koppelgebruiker en noteer waar de sleutel vandaan komt.
• Een scenario valt stil na fouten. Een scenario met een directe trigger stopt volgens Make bij de eerste fout, een gepland scenario na drie fouten op rij. Zonder melding merkt niemand dat. Hoe je dat afvangt, lees je in Make.com foutafhandeling.
• Een webhook zonder scenario. Make schakelt een webhook uit die langer dan vijf dagen aan geen enkel scenario hangt. Bouw je een koppeling om, controleer dan of het webhookadres nog actief is.
• Te veel tegelijk. Een webhook in Make verwerkt volgens de documentatie maximaal 300 verzoeken per tien seconden; daarboven worden verzoeken geweigerd. Voor de meeste mkb-processen is dat ruim, maar bij een grote import in één keer kan het knellen.
• Stille wijzigingen aan de andere kant. Een leverancier past zijn API aan of hernoemt een keuzelijst. Test je koppelingen na grote updates van een pakket, en houd de veldenlijst bij.

Wanneer is een Make-koppeling niet genoeg?

Make is sterk in het verplaatsen van losse records op het moment dat er iets gebeurt. Het is minder geschikt als je grote hoeveelheden data wilt verzamelen voor rapportages, of als dezelfde gegevens in vijf scenario's steeds opnieuw worden opgehaald en omgezet. Dan bouw je ongemerkt een tweede administratie in Make.

In dat geval is een centraal datafundament vaak slimmer: één plek waar je data schoon en gekoppeld klaarstaat, voor je dashboards én je workflows. Make blijft dan prima voor de acties, zoals een taak aanmaken of een melding sturen. Twijfel je of Make überhaupt het juiste platform is, lees dan ook Make vs n8n.

Hulp bij je Make.com koppeling?

Wil je twee systemen aan elkaar koppelen en weet je niet welke route past, of draait er al een koppeling die regelmatig hapert? We kijken graag mee naar je systemen en processen, en bouwen Make-koppelingen met een veldenlijst, foutafhandeling en een vaste eigenaar. Bekijk wat we doen op het gebied van workflow automation of lees hoe we werken.