Hoe u records kunt maken via de FileMaker Data API

U hebt een webformulier, een mobiele app of een ander systeem dat nieuwe records rechtstreeks naar FileMaker moet pushen — en u bent het zat CSVs te exporteren, importscripts uit te voeren of elke ochtend gegevens opnieuw in te voeren. Misschien verwerkt uw webshop een bestelling om 2 uur 's ochtends en bekijkt niemand deze tot het FileMaker-importscript om 9 uur wordt uitgevoerd. Dit gat is precies wat de FileMaker Data API is bedoeld om te dichten.

Dit artikel behandelt stap voor stap hoe u een record maakt via de Data API — de structuur van het verzoek, de verificatiestroom, de veelvoorkomende fouten en de ontwerp beslissingen die een script onderscheiden dat in tests werkt van een script dat productieverkeer aankan.

Wat is de FileMaker Data API, in eenvoudige termen?

De Data API is een REST-interface die ingebouwd is in FileMaker Server (en Claris Server) en waarmee elk extern systeem — een website, een Node.js-backend, een n8n- of Make-automatisering, een mobiele app — via standaard HTTP-aanroepen en JSON kan communiceren met een FileMaker-database, in plaats van ODBC, XML of een plug-in.

In plaats van een nachtelijk importscript krijgt u een live toegang tot uw database: elke app die een POST-aanvraag kan verzenden, kan op het moment zelf een record aanmaken. Dat is het verschil tussen een webbestelling van een klant die onmiddellijk in FileMaker terechtkomt versus in een CSV-map wacht tot iemand het importscript uitvoert.

Wat hebt u nodig voordat u een record kunt aanmaken?

Voordat u één regel code schrijft, bevestigt u deze vier dingen — de meeste "het werkt niet"-supporttickets kunnen worden herleid naar één ervan:

1. FileMaker Server of Claris Server voert het bestand uit en de Data API is voor die specifieke database ingeschakeld in de admin console (deze is standaard uitgeschakeld om veiligheidsredenen).
2. Een FileMaker-account met de juiste set privileges — het account moet "Toegang via Data API" aangevinkt hebben, plus create/edit-bevoegdheden op de doeltabel en layout.
3. Een layout gebouwd voor de API, niet noodzakelijk de layout die gebruikers op het scherm zien. Dit is belangrijker dan het klinkt — zie hieronder.
4. Een geldig SSL-certificaat op de server — zelf-ondertekende certificaten zullen veel HTTP-clients standaard blokkeren, wat veel eerste pogingen vanuit Postman of een browsergebaseerde app lam legt.

Hoe verifieert u zich bij de Data API?

Het aanmaken van een record is een dansje in twee stappen: inloggen en vervolgens het record verzenden.

Stap 1 — Haal een sessietoken op

POST https://yourserver.com/fmi/data/vLatest/databases/YourDatabase/sessions
Authorization: Basic base64(username:password)
Content-Type: application/json

FileMaker reageert met een token, standaard 15 minuten geldig zonder activiteit:

{
 "response": { "token": "1a2b3c4d5e6f..." },
 "messages": [ { "code": "0", "message": "OK" } ]
}

Stap 2 — Gebruik dat token bij elke volgende aanroep, in de header, niet in de body:

Authorization: Bearer 1a2b3c4d5e6f...

Een praktische valkuil: dat token verloopt na 15 minuten zonder activiteit — niet 15 minuten totaal. Als uw integratie elke uur een batch-job uitvoert, cacht u niet het token van gisteren; log elke run opnieuw in, of bouw logica in die een "401 / ongeldig token"-respons opvangen en automatisch opnieuw verificatie uitvoert vóór opnieuw proberen.

Hoe ziet de werkelijke create-record-aanvraag eruit?

Zodra u bent geverifieerd, is het aanmaken van een record één POST-aanroep:

POST https://yourserver.com/fmi/data/vLatest/databases/YourDatabase/layouts/API_Orders/records
Authorization: Bearer 1a2b3c4d5e6f...
Content-Type: application/json

{
 "fieldData": {
 "CustomerName": "Jansen Groothandel BV",
 "OrderDate": "03/14/2025",
 "OrderTotal": "1249.50",
 "Status": "New"
 }
}

Een succesvolle respons retourneert de interne ID en mod count van het nieuwe record:

{
 "response": { "recordId": "482", "modId": "0" },
 "messages": [ { "code": "0", "message": "OK" } ]
}

Onthoud die recordId — u zult deze nodig hebben als dezelfde integratie later dat record moet bijwerken of een bestand aan moet hechten.

Waarom moet u een toegewezen layout gebruiken in plaats van uw hoofdgegevensinvoerlayout?

Dit is de fout die later de meest verwarrende bugs veroorzaakt. De Data API ziet alleen velden die op de layout bestaan waarnaar u verwijst — niet de hele tabel.

Als uw bestellinginvoerlayout een berekeningsveld, een portal of een containerveld bevat dat de API-aanroep niet verwacht, kunt u stille fouten, onverwacht auto-enter-gedrag of prestatieachteruitgang van onnodig geladen portals krijgen. De oplossing: bouw een slanke, toegewezen layout — iets als API_Orders — die alleen de velden toont die de integratie werkelijk moet lezen of schrijven. Dit geeft u ook een stabiel contract: uw zichtbare UI-layout kan vrij worden opnieuw ontworpen zonder ooit de integratie te breken, omdat de API deze niet aanraakt.

Hoe stelt u gerelateerde velden in of maakt u een parent- en child-record tegelijk aan?

Een veelvoorkomend scenario: het aanmaken van een nieuwe Order plus de bijbehorende Line Items in één aanroep, in plaats van twee ronde reizen. De Data API ondersteunt dit via portalData:

{
 "fieldData": {
 "CustomerName": "Jansen Groothandel BV",
 "OrderDate": "03/14/2025"
 },
 "portalData": {
 "LineItems": [
 { "ProductName": "Widget A", "Qty": "4", "Price": "12.50" },
 { "ProductName": "Widget B", "Qty": "1", "Price": "39.00" }
 ]
 }
}

De portalnaam in de JSON moet exact overeenkomen met de objectnaam van de portal op de layout — niet de naam van de gerelateerde tabel. Dit valleert bijna iedereen de eerste keer, omdat de FileMaker-layout-inspector standaard de naam van het tableauvoorkomen toont; u moet de portaalobject expliciet een naam geven.

Hoe moet u fouten afhandelen zodat de integratie niet stilzwijgend faalt?

In een echte productie-integratie — zeg, een webshop die de hele dag orders naar FileMaker pusht — zal af en toe iets fout gaan: een verplicht veld ontbreekt, een waarde mislukt validatie, de sessietoken verloopt halverwege de batch, of de server is midden in een back-up en is even onbeschikbaar. Plan er rekening mee:

• Controleer de messages[0].code op elke respons. "0" betekent succes; alles anders is een fout waarvoor u moet aftakken. Ga niet ervan uit dat een HTTP-status 200 betekent dat het record is aangemaakt — FileMaker kan HTTP 200 retourneren met een foutcode in de body.
• Probeer alleen opnieuw bij tokenverval (401/952), niet bij validatiefouten. Een slechte veldwaarde zal elke keer dat u het opnieuw probeert mislukken; blindelings opnieuw proberen verspilt alleen aanroepen en verbergt een echt gegevensprobleem.
• Log de payload die is mislukt, niet alleen de foutcode. Wanneer een klant zegt "drie orders zijn nooit verschenen," moet u precies zien wat is verzonden, niet alleen dat iets is mislukt.
• Stel een redelijke timeout en een wachtrij in. Als uw bronsysteem in één seconde 50 records afvuurt, kan het tegelijk versturen ervan een laag-niveau FileMaker Server overbelasten. Een kleine wachtrij met een korte vertraging tussen aanroepen is veel betrouwbaarder dan een stroomstoot.

Wat zijn veelvoorkomende redenen waarom het aanmaken van records mislukt, en hoe lost u elk ervan op?

Symptoom	Waarschijnlijke oorzaak	Oplossing
401 Unauthorized	Token verlopen of nooit verkregen	Verificatie opnieuw uitvoeren, controleer of het account "Toegang via Data API" heeft
"Field is missing" of stilzwijgende veldval	Veld niet op de doellayout	Voeg het veld toe aan uw toegewezen API-layout
500-fout met cryptisch bericht	Waarde mislukt een validatieregel of berekening	Controleer veldvalidatie-instellingen; test dezelfde waarde handmatig in FileMaker
Portalgegevens niet opgeslagen	Portaalobject-naamconflict	Wijzig naam in JSON zodat deze exact overeenkomt met de portaalobjectnaam van de layout
Werkt in Postman, faalt vanuit de app	SSL-certificaat niet vertrouwd door de client	Installeer een geldig CA-ondertekend certificaat op de server
Intermittente fouten onder belasting	Te veel gelijktijdige aanroepen	Voeg een aanvraagwachtrij in / vertraag aan de verzendende zijde

Moet u dit bouwen met normale scripts, of voegt u een framework bovenop, zoals FMBetterForms of AI?

Raw Data API-aanroepen werken goed voor eenvoudige integraties — één systeem dat orders, leads of tickets in FileMaker pusht. Maar twee situaties veranderen de berekening:

• U hebt een gepolijst extern formulier nodig. Als klanten of veldmedewerkers de gegevens invullen die uiteindelijk een FileMaker-record worden, kunt u met een tool als FMBetterForms een modern, responsief webformulier bouwen dat rechtstreeks via de Data API naar FileMaker plaatst — zonder niet-technische gebruikers JSON of Postman aan te raken.
• U wilt dat het systeem ongestructureerde invoer interpreteert voordat u het record aanmaakt. Dit is waar AI steeds vaker in FileMaker-workflows wordt gebruikt: een inkomend e-mailbericht, een gescande PO of een tekstbericht zonder vaste opmaak via WhatsApp wordt door een AI-model geparst, toegewezen aan gestructureerde velden en vervolgens via dezelfde hierboven beschreven Data API create-record-aanroep naar FileMaker geschreven. De API-aanroep zelf verandert niet — wat verandert is wat de JSON-payload genereert.

In beide gevallen is de onderliggende mechanica identiek aan wat in dit artikel wordt beschreven: verificatie, POST fieldData naar een toegewezen layout, afhandeling van de respons. De complexiteit verschuift naar wat voor de API-aanroep gebeurt, niet de aanroep zelf.

Hoe past dit in een bredere FileMaker-integratiestrateggie?

Het aanmaken van records is meestal slechts één onderdeel van een grotere verbinding tussen FileMaker en de rest van uw softwarestack — u zult ook records moeten lezen, bijwerken en acties in de andere richting activeren. Als u dat grotere plaatje uitbouwt, behandelt onze gids over hoe u FileMaker met moderne applicaties en services kunt verbinden het volledige bereik van integratiepatronen buiten alleen recordaanmaak.

Snelle checklist voordat u live gaat

• Data API ingeschakeld voor het specifieke bestand in FileMaker Server admin console
• Toegewezen account met "Toegang via Data API" en juiste set privileges
• Geldig, CA-ondertekend SSL-certificaat geïnstalleerd op de server
• Toegewezen, minimale API-layout — niet uw hoofd-UI-layout
• Logica voor tokenvernieuging voor langlopende of geplande integraties
• Foutcode-controle op elke respons, niet alleen HTTP-status
• Logging van mislukte payloads voor probleemoplossing
• Vertraging/wachtrij als het bronsysteem veel aanvragen tegelijk kan afvuren

Veelgestelde vragen

Kan de Data API meer dan één record per aanroep aanmaken? Niet rechtstreeks voor de parent-tabel — elke aanroep naar het records-eindpunt maakt één record aan. U kunt gerelateerde child-records in dezelfde aanroep maken via portalData, en u kunt een lus schrijven om snel meerdere aanroepen te verzenden, maar er is geen native "bulk insert"-eindpunt.

Activeert het aanmaken van een record via de Data API FileMaker-scripts? Alleen als u dit expliciet aanvraagt. U kunt een script-parameter in dezelfde aanroep doorgeven om een server-side-script uit te voeren nadat het record is aangemaakt — handig voor het verzenden van een melding, het bijwerken van een gerelateerd record of het starten van verdere logica.

Is de Data API snel genoeg voor integraties met groot volume? Voor matig volume (tientallen tot enkele honderden records per minuut) presteert dit goed op adequaat groot FileMaker Server-hardware. Voor zeer groot volume, bijna-realtime streams, maakt u een wachtrij aan de verzendende zijde in plaats van aanvragen zo snel mogelijk af te vuren.

Moet u FileMaker Pro installeren om de Data API te gebruiken? Nee — de Data API is een server-side-functie. Het verzendende systeem hoeft alleen standaard HTTPS-aanroepen te doen; geen FileMaker-clientsoftware is aan die kant vereist.

Als u weegt of u deze integratie in-house bouwt, een frontend-formulier bovenop toevoegt, of AI in de mix betrekt om rommelige inkomende gegevens af te handelen voordat deze FileMaker bereikt, is het handig om eerst de volledige stroom in kaart te brengen. Loggix bouwt aangepaste FileMaker-oplossingen en API-integraties precies zoals dit, en kan ook advies geven over waar een tool als FMBetterForms of een AI-parsing-stap echt tijd bespaart in plaats van onnodige complexiteit voor uw specifieke geval toevoegt.