Wat is de FileMaker Data API?

U hebt een FileMaker-systeem dat uw bestellingen, voorraad of clientgegevens beheert — en nu wil iemand dat het met uw webshop, uw boekhoudpakket of een aangepaste mobiele app kan communiceren. Het oude antwoord was altijd "exporteer een CSV en importeer deze ergens anders, volgens een schema, en hoop maar dat niemand het bestand tussentijds aanpast." Dat is traag, foutgevoelig en betekent dat uw gegevens nooit helemaal synchroon lopen. De FileMaker Data API lost precies dit probleem op: het stelt andere software in staat om rechtstreeks, in real-time, uit uw FileMaker-systeem te lezen en erin te schrijven, zonder dat iemand een exportknop hoeft in te drukken.

Dit artikel legt uit wat de FileMaker Data API eigenlijk is, hoe het onder de motorkap werkt, waar het zich verhouden tot andere FileMaker-verbindingsmethoden, en waar u op moet letten wanneer u ervan bouwt.

Wat is de FileMaker Data API eigenlijk precies?

De FileMaker Data API is een REST API die Claris (het bedrijf achter FileMaker) rechtstreeks in FileMaker Server en FileMaker Cloud heeft ingebouwd. "REST" betekent gewoon dat het dezelfde taal spreekt die bijna elke moderne webservice, app en integratieplatform al begrijpt: HTTP-verzoeken en JSON-antwoorden.

In de praktijk betekent dit dat elk systeem dat HTTP-oproepen kan doen — een webshop op Shopify of WooCommerce, een Node.js-script, een Python-taak, een iPaaS-tool zoals Make of Zapier, of een aangepaste web-app — kan:

• Inloggen en een sessietoken ophalen
• Records zoeken (met zoekcriteria, sortering en paginering)
• Nieuwe records maken
• Bestaande records bewerken
• Records verwijderen
• Containergegevens uploaden of downloaden (bestanden, afbeeldingen, PDF's)
• FileMaker-scripts op afstand uitvoeren, en zelfs scripts triggeren op recordgebeurtenissen

Geen plugin, geen tussenlaag nodig aan de FileMaker-kant — het is ingebouwd in het platform zelf en ingeschakeld per databasebestand.

Hoe werkt het eigenlijk, stap voor stap?

Hier ziet een echte integratie er in de praktijk uit, met behulp van een bestellingssynchronisatie als voorbeeld:

1. Authenticatie. Het externe systeem stuurt een verzoek naar /fmi/data/v1/databases/UwBestand/sessions met een gebruikersnaam en wachtwoord (of een OAuth-token). FileMaker Server retourneert een sessietoken.
2. Een layout adresseren. De Data API werkt altijd via een FileMaker-layout — niet rechtstreeks op een tabel. Dus u maakt normaal gesproken een dedicated API-layout die precies de velden blootstelt die u wilt, niet meer.
3. Het verzoek verzenden. Voor een nieuwe bestelling is dat een POST-verzoek naar het recordseindpunt voor die layout, met de bestellingsgegevens als JSON in de body.
4. FileMaker valideert en schrijft. Alle validatieregels, auto-enter-berekeningen en scripts die door die layout worden geactiveerd, worden nog steeds uitgevoerd — de Data API omzeilt uw bedrijfslogica niet.
5. Een antwoord ontvangen. FileMaker geeft de nieuwe record-ID en alle veldgegevens die u aanvraagde terug, als JSON.
6. Sluit de sessie. Tokens verlopen standaard na 15 minuten inactiviteit, dus langdurige integraties moeten herverificatie afhandelen.

Een concreet voorbeeld: een Loggix-klant die een groothandelsbedrijf runt, ontving bestellingen via een webportaal gebouwd in een ander framework. In plaats van de bestellingen van die portal naar zijn eigen database te schrijven en 's nachts te synchroniseren, roept de portal de FileMaker Data API aan op het moment dat een klant een bestelling indient. De bestelling verschijnt in FileMaker's bestellingenwachtrij binnen een seconde, de voorraad wordt gereserveerd door het bestaande FileMaker-script, en het magazijnteam ziet het nog voordat de bevestigingse-mail van de klant wordt verzonden.

Hoe verschilt dit van ODBC, XML of de oude PHP API?

FileMaker heeft door de jaren heen verschillende manieren gehad om contact te maken met de buitenwereld, en het is nuttig om te weten waarom de Data API nu over het algemeen wint:

Methode	Geschikt voor	Nadeel
ODBC/JDBC	SQL-achtige query's van BI-tools, rapportage	Lees-intensief, omslachtig voor schrijven, problemen met verbindingspooling op schaal
XML/PHP API	Legacy-webpublicatie	Verouderd door Claris, niet langer actief ontwikkeld
FileMaker Data API (REST)	Moderne app-naar-app-integratie, mobiele apps, webshops	Vereist FileMaker Server/Cloud (niet beschikbaar op FileMaker Pro alleen)
Aangepaste plugins (bijv. voor directe API-oproepen naar buiten)	FileMaker roept uit naar andere services	Andere richting — dit is FileMaker als client, niet server

Het belangrijkste onderscheid: de Data API maakt FileMaker zelf tot een API-server — andere systemen roepen in. Als u daarentegen FileMaker uit naar een andere service wilt laten roepen (zeg, een factuur naar een boekhoud-API pushen), wordt dit meestal gedaan met FileMaker's ingebouwde scriptstap Insert from URL of een plugin, wat een gerelateerd maar afzonderlijk onderwerp is dat behandeld wordt in onze bredere gids over hoe u FileMaker verbindt met moderne toepassingen en services.

Wat kunt u er eigenlijk mee bouwen?

Enkele real-world-patronen die we herhaaldelijk zien:

• Klantgerichte portals. Een web- of mobiele front-end waar klanten facturen bekijken, verzoeken indienen of bestellingen traceren — terwijl de eigenlijke gegevens en bedrijfslogica in FileMaker blijven.
• E-commerce-synchronisatie. Bestellingen op een webshop stromen automatisch in FileMaker, en voorraadiniveaus worden na elke verkoop teruggespiegeld op de webshop.
• Mobiele veldapps. Technici vullen een native of web-app ter plaatse in; de Data API duwt die gegevens rechtstreeks in het FileMaker-systeem dat door het back-office wordt gebruikt.
• Door AI ondersteunde workflows. Een chatbot of AI-agent (iets wat we hebben gebouwd met tools zoals Klai) bevraagt FileMaker via de Data API om vragen te beantwoorden zoals "hoeveel eenheden van product X hebben we nog over?" of om een nieuw potentieel klant in te loggen zonder dat een mens FileMaker aanraakt.
• Moderne webformulieren. Tools zoals FmBetterforms genereren schone, mobiel vriendelijke webformulieren die rechtstreeks in FileMaker via de Data API worden ingediend — handig wanneer de native FileMaker WebDirect-interface te zwaar of te omslachtig voelt voor een openbare vorm.

Wat zijn de valkuilen waar mensen tegenaan lopen?

Dingen die teams de eerste keer dat zij op de Data API bouwen, verrassen:

• U hebt FileMaker Server of Cloud nodig. Een enkel FileMaker Pro-bestand op iemands laptop kan de Data API niet serveren — het moet worden gehost.

• Licenties en het inschakelen ervan. De Data API moet expliciet per bestand in FileMaker Server's beheerconsole worden ingeschakeld, en afhankelijk van uw Claris-licentie, kunnen API-oproepen tegen gebruikslimieten tellen.

• Layouts zijn uw toegangscontrole. Omdat elk verzoek via een layout gaat, zijn alle velden op die layout blootgesteld. Bouw dedicated, minimale API-layouts — verwijs externe oproepen niet zomaar naar uw hoofdgegevensinvoerlayout.

• Verlopen van sessietoken. Langdurige scripts of trage integraties hebben herhalinglogica nodig voor verlopen tokens, anders mislukken zij stil.

• Geen native rate limiting of throttling. Als een slecht geschreven script de API bombardeert, kan uw FileMaker Server voor iedereen anders die het bestand tegelijkertijd gebruikt vertragen. Bouw zinvol batching en vertragingen in elke bulksynchronisatie.

• Foutafhandeling is uw werk. De API geeft foutcodes terug, maar het zal u niet vertellen waarom een webshopbestelling niet aan een klantrecord kan worden gekoppeld — die logica moet in uw integratielaag wonen.

Checklist: is de Data API het juiste voor uw situatie?

• U hebt real-time (niet batch/nacht) gegevensstroom tussen FileMaker en een ander systeem nodig
• Het andere systeem kan HTTP-verzoeken doen (wat waar is voor bijna alles dat na 2015 is gebouwd)
• Uw FileMaker-bestand wordt gehost op FileMaker Server of FileMaker Cloud
• U bent comfortabel met het bouwen en onderhouden van dedicated API-layouts, apart van uw dagelijkse werklay-outs
• U hebt (of kunt krijgen) iemand die zowel FileMaker-scripting als basale REST/JSON-concepten begrijpt om de integratie te bouwen en te onderhouden

Als de meeste van deze waar zijn, is de Data API zeer waarschijnlijk uw beste optie. Als u FileMaker de oproeper moet laten zijn, of u integreert met een SQL-rapportagetool, kijk dan naar Insert from URL-scripting of ODBC in plaats daarvan.

Veelgestelde vragen

Kost de FileMaker Data API extra? Het is inbegrepen bij FileMaker Server en FileMaker Cloud-licenties — er is geen apart bedrag voor de API zelf, maar uw Claris-hostingplan kan gebruiksgebaseerde limieten hebben die het waard zijn om te controleren.

Kan ik de Data API gebruiken met alleen FileMaker Pro, zonder een server? Nee. De Data API wordt geserveerd door FileMaker Server of FileMaker Cloud. Een bestand dat alleen in FileMaker Pro op een desktop open is, kan geen API-verzoeken beantwoorden.

Is de Data API veilig genoeg voor productiegebruik? Ja, indien correct ingesteld: gebruik HTTPS (standaard afgedwongen), beperk toegang via dedicated layouts en privilege sets, en stel admin-accounts niet bloot aan externe systemen.

Kan de Data API FileMaker-scripts uitvoeren, niet alleen gegevens verplaatsen? Ja — het kan scripts op de server triggeren, wat vaak hoe teams de eenvoud van een REST-oproep combineren met FileMaker's bestaande bedrijfslogica, in plaats van die logica in het externe systeem te dupliceren.

Als u afweegt of de Data API, een aangepaste connector of een bredere integratiestrategieën de juiste stap voor uw specifieke systemen is, dat is precies het soort vraag dat Loggix met clients uitwerkt voordat een enkele coderegel wordt geschreven — soms is het antwoord een lean API-layout bovenop uw bestaande FileMaker-systeem, soms is het een kleine aangepaste web-app, en soms is het het toevoegen van een AI-laag bovenop gegevens die al daar zijn. Hoe dan ook, het begrijpen van wat de Data API kan en niet kan doen is de eerste stap om die keuze met vertrouwen te maken.