FileMaker webhooks gebruiken

Je webshop stuurt een orderbevestiging. Je verzendpartner werkt een trackingstatus bij. Je betaalprovider markeert een factuur als betaald. Dit gebeurt allemaal in real time, in systemen die buiten FileMaker bestaan — en op dit moment ververst iemand van je team ofwel een dashboard om te zien of er iets is veranderd, of kopieert deze update handmatig in je FileMaker-oplossing als ze het opmerken. Dat is het probleem dat webhooks oplossen: in plaats van dat FileMaker om de paar minuten vraagt "is er iets nieuws?", tikt het andere systeem FileMaker op de schouder het moment iets gebeurt.

Dit artikel loopt je stap voor stap door exact hoe je dat instelt — beide richtingen: FileMaker ontvangt webhooks van andere systemen, en FileMaker verzendt webhooks uit.

Wat is een webhook, in eenvoudige termen?

Een webhook is een klein HTTP-bericht dat het ene systeem naar het andere stuurt op het moment dat iets gebeurt — geen polling, geen geplande controle, geen vertraging. Zie het als het tegenovergestelde van een API-aanroep die je zelf initieert. In plaats van dat je FileMaker-script Shopify vraagt "heb je nieuwe bestellingen?" om de vijf minuten, stuurt Shopify FileMaker een bericht het moment een bestelling binnenkomt: "hier is bestelling #4821, hier is de klant, hier is het totaal."

Onder de motorkap is een webhook bijna altijd:

• een HTTP POST-verzoek
• met een JSON (soms XML) payload in de body
• verzonden naar een URL die je controleert
• vaak ondertekend of geverifieerd met een token of geheim, zodat je de afzender kunt vertrouwen

Dat is het. Geen speciaal protocol, geen propriëtaire indeling — wat precies maakt dat het natuurlijk past bij FileMaker's Data API en scripttriggers.

Waarom hebben FileMaker-teams webhooks nodig?

In de praktijk is de trigger bijna altijd een van deze situaties:

• Een e-commercebestelling moet direct in FileMaker terechtkomen, niet vijf minuten later, zodat het magazijnteam kan gaan picken voordat de klant zelfs hun bevestigingse-mail krijgt.
• Een betalingsstatus verandert in Mollie, Stripe of Exact Online, en de factuurrecord in FileMaker moet naar "betaald" gaan zonder dat iemand handmatig controleert.
• Een supportticket wordt aangemaakt in een helpdesktool, en het moet in het FileMaker CRM verschijnen op het moment dat het wordt geopend, gelabeld aan de juiste klantrecord.
• Een ondertekend document komt terug van een service zoals DocuSign of Signable, en de FileMaker-contractrecord moet automatisch bijgewerkt worden.

In elk van deze gevallen werkt polling — een geplande script die om de 5 of 15 minuten controleert — technisch gezien, maar het is langzamer, het put de externe API uit met onnodige aanvragen, en het kan snel je tarieflimieten verbruiken als je tientallen records "voor het geval dat" controleert. Webhooks draaien dat model om: FileMaker zit rustig tot iets werkelijk gebeurt, en reageert dan onmiddellijk.

Hoe ontvang je een webhook in FileMaker?

FileMaker zelf heeft geen ingebouwd "webhook listener" zoals, zeg, een Node.js-server — FileMaker Server voert standaard geen open HTTP-eindpunt uit dat wacht op willekeurige inkomende POSTs. Dus webhooks ontvangen vergt één van twee benaderingen:

Optie 1: Een lichte middleware-eindpunt voor FileMaker

Je zet een klein eindpunt op (vaak een klein script op je eigen server, of een serverloze functie) waarvan de enige taak is:

1. Het inkomende POST van de externe service accepteren.
2. De handtekening/secret valideren zodat je weet dat het echt is.
3. De payload indien nodig herindelen.
4. De FileMaker Data API aanroepen om een record met die gegevens te maken of bij te werken.

Dit is het patroon dat we bij Loggix meestal gebruiken, omdat het FileMaker Server zelf onaangetast laat — het hoeft nooit te worden blootgesteld als een openbare webhontontvanger — en het geeft je een plek om mislukte leveringen te loggen, opnieuw proberen en debuggen voordat FileMaker het ooit ziet.

Optie 2: FileMaker Data API als directe ontvanger

Sommige tools laten je een webhook rechtstreeks naar een Data API-eindpunt wijzen met een token in de header. Dit werkt voor eenvoudige gevallen, maar het heeft echte beperkingen: Data API-tokens verlopen, de payloadindeling moet precies aansluiten op wat je script verwacht, en er is geen gemakkelijke plek om een mislukte levering te inspecteren of opnieuw af te spelen. We raden dit over het algemeen alleen aan voor interne, weinig risicovolle integraties — niet voor iets met betrekking tot klanten zoals betalingsbevestigingen.

Stap voor stap: instellen van een inkomende webhook

1. Kies of bouw je ontvangendpunt (middleware-functie of een Data API-eindpunt).
2. Zorg ervoor dat de webhook-URL is geregistreerd in het verzendende systeem (Shopify, Mollie, DocuSign, je helpdesk, enzovoort).
3. Voeg een gedeeld geheim of handtekening toe — accepteer nooit een unauthenticated POST als waarheid.
4. Wijs de inkomende JSON-velden toe aan je FileMaker-schema. Ga niet ervan uit dat veldnamen overeenkomen; bouw een vertaaglaag.
5. Schrijf het FileMaker-script dat de record maakt/bijwerkt, met de Data API of een gescripte Insert from URL / serverside script dat door de middleware wordt geactiveerd.
6. Log elke inkomende payload, minstens tijdelijk, zodat je, als iets drie weken later verkeerd lijkt, precies kunt zien wat er werd verzonden.
7. Verwerk duplicaten en pogingen opnieuw. De meeste webhontverzenders proberen het opnieuw bij een time-out — bouw je script zo dat dezelfde bestelling twee keer ontvangen geen twee records maakt.

[[IMAGE:left|externe service verzendt webhook POST in FileMaker via middleware-eindpunt]]

Hoe verzendt je een webhook vanuit FileMaker?

Deze richting is eenvoudiger, omdat FileMaker de initiator is en je volledig controle hebt.

1. Gebruik de Insert from URL scriptstap (of de nieuwere curl-opties in recente FileMaker-versies) met de HTTP-methode ingesteld op POST.
2. Bouw de JSON-payload uit je FileMaker-velden — gebruik de JSONSetElement-functie om het schoon op te bouwen in plaats van JSON met tekenreeksen samen te voegen.
3. Stel de doel-URL in op wat het ontvangende systeem verwacht (een Slack-kanaalhook, een Zapier/Make-vangst, je eigen middleware, enzovoort).
4. Activeer het script vanuit de gebeurtenis die belangrijk is: een record commit, een statusveld dat verandert, een knopdruk, of een servergeplande taak.
5. Leg de antwoordcode en body vast, en schrijf deze naar een logveld — fire-and-forget niet zwijgend, of je zult nooit weten wanneer een levering begon te mislukken.

Een veelgebruikt echt voorbeeld: wanneer een factuurrecord in FileMaker is gemarkeerd als "Verzonden", activeert een script een webhook naar Slack, zodat het financiële team een instant melding in hun #invoices-kanaal krijgt — niemand hoeft FileMaker zelf te controleren om te weten dat het verzonden is.

Hoe zit het met FmBetterForms en Klai — passen deze erin?

Ja, op twee verschillende manieren.

FmBetterForms wordt vaak gebruikt om moderne webfacing-formulieren en portals te bouwen die de webhookgebeurtenissen genereren waar we mee beginnen — een klantgericht ingevingsformulier, een aanmeldingspagina of een goedkeuringsvorm die deels buiten de native FileMaker-client leeft. Wanneer iemand dat formulier indient, is het een natuurlijk triggerpunt om een webhook (of rechtstreeks de Data API aan te roepen) in de kernFileMaker-oplossing af te vuren, zodat de weblaag en de gegevenslaag schoon gescheiden blijven.

Klai, als een AI-laag in FileMaker, is nuttig aan de ontvangende kant. Zodra een webhookpayload aankomt — een supportticket, een contract, een lang klantenbericht — kan Klai worden gebruikt om het samen te vatten, in te delen of een voorgesteld antwoord op te stellen voordat iemand het record zelfs opent. Dus de webhook brengt de gegevens direct naar binnen, en de AI-laag maakt die directe levering daadwerkelijk nuttig, in plaats van alleen maar sneller.

Wat gaat er meestal mis met FileMaker webhooks?

• Geen retry-handling — de webhook van de afzender loopt eenmaal uit, en die record gaat stilletjes voor altijd verloren tenzij je retry-logica of minstens waarschuwingen hebt gebouwd.
• Geen idempotentiecontrole — dezelfde gebeurtenis arriveert twee keer (wat vaker gebeurt dan mensen denken) en maakt een dubbele record.
• Harde afhankelijkheid van FileMaker Server-uptime — als FileMaker Server down is voor onderhoud en er is geen middleware-buffer, mislukken inkomende webhooks gewoon zonder enig teken dat ze ooit zijn aangekomen.
• Unauthenticated-eindpunten — accepteert ieder POST zonder een handtekening of geheim te controleren opent de deur voor vervalste gegevens.
• Schema drift — de externe service verandert zijn payloadindeling in een update, en niemand merkt het totdat records leeg beginnen aan te komen.

Checklist: is je FileMaker webhook-instellingen productie-klaar?

• Elke inkomende webhook is geverifieerd (handtekening of gedeeld geheim)
• Payloads worden voor verwerking gelogd, gedurende minstens een rollend venster
• Dubbele leveringen maken geen dubbele records
• Mislukte leveringen worden opnieuw geprobeerd of gewaarschuwd, niet stilletjes weggegooid
• Er is een middleware-buffer als FileMaker Server niet altijd bereikbaar is
• Uitgaande webhooks loggen hun antwoordcode/body
• Iemand is eigenaar van het controleren hiervan — het is niet "instellen en vergeten"

Veel gestelde vragen

Kan FileMaker Server rechtstreeks webhooks ontvangen, zonder middleware? Technisch gezien ja, via de Data API, maar het is fragiel voor iets dat bedrijfskritiek is — geen ingebouwde retry-buffering, geen gemakkelijke inspectie van mislukte aanroepen, en tokenbeheer voegt wrijving toe. Voor intern of weinig riskant gebruik is het prima; voor betaling- of ordergegevens is een middleware-laag het extra setup waard.

Vervangen webhooks de behoefte aan een volledige API-integratie? Nee — webhooks zijn ereignisberichten, geen volledig gegevenssynchronisatiemechanisme. Je hebt doorgaans nog steeds API-aanroepen nodig voor het ophalen van historische gegevens, batchsynchronisaties, of iets dat de webhook niet dekte. Webhooks handelen het "vertel me het moment dit gebeurt" deel; API's handelen de rest.

Is FileMaker's Data API vereist om webhooks helemaal te gebruiken? Voor ontvangen, ja, in de meeste instellingen — het is het mechanisme dat werkelijk de inkomende gegevens in records schrijft. Voor verzenden hoef je de Data API niet; Insert from URL vanuit een script is genoeg.

Hoe verschilt dit van wat in de bredere connectiviteitsgids wordt behandeld? Als je het bredere plaatje wilt — hoe webhooks naast API-connectoren, middleware-platforms en andere integratiepatronen voor het koppelen van FileMaker aan moderne SaaS-tools passen — zie de volledig overzicht op hoe FileMaker aan moderne toepassingen en services verbinden.

Webhooks goed krijgen in FileMaker gaat minder over de scriptstap zelf en meer over de omringende leidingen — authenticatie, logging, retries en bepalen wanneer een middleware-laag het bouwen waard is. Als je afweegt of je huidige instellingen (of een geplande integratie met een webshop, betaalprovider of helpdesktool) die middleware-laag nodig hebben, of of Data API alleen volstaat, kan Loggix de juiste architectuur met je in kaart brengen — van een aangepaste FileMaker-build, tot een API-connector, tot het toevoegen van een AI-laag zoals Klai bovenop de gegevens die binnenkomen.