[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fSL9zoDCwA53YLyO3ooR4rVb2cOjKNwm7aJwcYdhhoa0":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":25,"hasDownload":26,"fileName":27,"youtubeId":28,"domainCrumb":29,"clusterCrumb":32},"384","5267DA6F-303F-BC46-8FDD-F8E9D39CFDDF","E46BDB0A-2979-1E40-93F7-AC40185848A5","33710AE6-6A9E-F741-A6A4-9DFCC5810440","article","what-is-the-filemaker-data-api","What is the FileMaker Data API?","A practical explanation of what the FileMaker Data API is, how it works, and when it's the right way to connect FileMaker to other systems.","You've got a FileMaker system running your orders, inventory, or client records — and now someone wants it to talk to your webshop, your accounting package, or a custom mobile app. The old answer used to be \"export a CSV and import it somewhere else, on a schedule, and hope nobody edits the file in between.\" That's slow, error-prone, and it means your data is never quite in sync. The FileMaker Data API solves exactly this problem: it lets other software read from and write to your FileMaker system directly, in real time, without anyone touching an export button.\n\nThis article explains what the FileMaker Data API actually is, how it works under the hood, where it fits next to other FileMaker connection methods, and what to watch out for when you build on it.\n\n## What exactly is the FileMaker Data API?\n\nThe FileMaker Data API is a REST API that Claris (the company behind FileMaker) built directly into FileMaker Server and FileMaker Cloud. \"REST\" just means it speaks the same language almost every modern web service, app, and integration platform already understands: HTTP requests and JSON responses.\n\nIn practice, that means any system capable of making an HTTP call — a webshop on Shopify or WooCommerce, a Node.js script, a Python job, an iPaaS tool like Make or Zapier, or a custom web app — can:\n\n- Log in and get a session token\n- Find records (with search criteria, sorting, and pagination)\n- Create new records\n- Edit existing records\n- Delete records\n- Upload or download container data (files, images, PDFs)\n- Run FileMaker scripts remotely, and even trigger scripts on record events\n\nNo plugin, no middleware layer required on the FileMaker side — it's built into the platform itself and switched on per database file.\n\n## How does it actually work, step by step?\n\nHere's what a real integration looks like in practice, using an order sync as an example:\n\n1. **Authenticate.** The external system sends a request to `\u002Ffmi\u002Fdata\u002Fv1\u002Fdatabases\u002FYourFile\u002Fsessions` with a username and password (or an OAuth token). FileMaker Server returns a session token.\n2. **Address a layout.** The Data API always works through a FileMaker layout — not directly on a table. So you typically build a dedicated API layout that exposes exactly the fields you want to expose, nothing more.\n3. **Send the request.** For a new order, that's a POST request to the records endpoint for that layout, with the order data as JSON in the body.\n4. **FileMaker validates and writes.** Any validation rules, auto-enter calculations, and scripts triggered by that layout still run — the Data API doesn't bypass your business logic.\n5. **Get a response back.** FileMaker returns the new record ID and any field data you asked for, as JSON.\n6. **Close the session.** Tokens expire after 15 minutes of inactivity by default, so long-running integrations need to handle re-authentication.\n\nA concrete example: a Loggix client running a wholesale operation had orders coming in through a web portal built in a separate framework. Instead of writing that portal's orders to its own database and syncing overnight, the portal calls the FileMaker Data API the moment a customer submits an order. The order appears in FileMaker's order queue within a second, stock gets reserved by the existing FileMaker script, and the warehouse team sees it before the customer's confirmation email even arrives.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F252?w=700&f=webp\" alt=\"external app sending JSON request to FileMaker Server, response returning\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## How is this different from ODBC, XML, or the old PHP API?\n\nFileMaker has had several ways to connect to the outside world over the years, and it's worth knowing why the Data API generally wins now:\n\n| Method | Good for | Downside |\n|---|---|---|\n| **ODBC\u002FJDBC** | SQL-style queries from BI tools, reporting | Read-heavy, clunky for writes, connection pooling issues at scale |\n| **XML\u002FPHP API** | Legacy web publishing | Deprecated by Claris, no longer actively developed |\n| **FileMaker Data API (REST)** | Modern app-to-app integration, mobile apps, webshops | Requires FileMaker Server\u002FCloud (not available on FileMaker Pro alone) |\n| **Custom plugins (e.g. for direct API calls out)** | FileMaker calling *out* to other services | Different direction — this is FileMaker as the client, not the server |\n\nThe key distinction: the Data API turns FileMaker itself into an API *server* — other systems call in. If you instead need FileMaker to call *out* to another service (say, pushing an invoice to an accounting API), that's usually done with FileMaker's built-in `Insert from URL` script step or a plugin, which is a related but separate topic covered in our broader guide on [how to connect FileMaker to modern applications and services](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-connect-filemaker-to-modern-applications-and-services).\n\n## What can you actually build with it?\n\nSome real-world patterns we see repeatedly:\n\n- **Customer-facing portals.** A web or mobile front-end where customers view invoices, submit requests, or track orders — while the actual data and business logic stay in FileMaker.\n- **E-commerce sync.** Orders placed on a webshop flow into FileMaker automatically, and stock levels update back on the webshop after each sale.\n- **Mobile field apps.** Technicians fill in a native or web app on-site; the Data API pushes that data straight into the FileMaker system used by the back office.\n- **AI-assisted workflows.** A chatbot or AI agent (something we've built with tools like Klai) queries FileMaker through the Data API to answer questions like \"how many units of product X do we have left?\" or to log a new lead without a human touching FileMaker directly.\n- **Modern web forms.** Tools like FmBetterforms generate clean, mobile-friendly web forms that submit straight into FileMaker via the Data API — useful when the native FileMaker WebDirect interface feels too heavy or too clunky for a public-facing form.\n\n## What are the gotchas people run into?\n\nThings that catch teams off guard the first time they build on the Data API:\n\n- **You need FileMaker Server or Cloud.** A solo FileMaker Pro file on someone's laptop can't serve the Data API — it has to be hosted.\n- **Licensing and enabling it.** The Data API must be explicitly enabled per file in FileMaker Server's admin console, and depending on your Claris licensing, API calls may count against usage limits.\n- **Layouts are your access control.** Because every request goes through a layout, whatever fields are on that layout are exposed. Build dedicated, minimal API layouts — don't just point external calls at your main data-entry layout.\n- **Session token expiry.** Long-running scripts or slow integrations need retry logic for expired tokens, or they'll silently fail.\n- **No native rate limiting or throttling.** If a badly written script hammers the API, your FileMaker Server can slow down for everyone else using the file at the same time. Build sensible batching and delays into any bulk sync.\n\n- **Error handling is your job.** The API returns error codes, but it won't tell you *why* a webshop order failed to map to a customer record — that logic has to live in your integration layer.\n\n## Checklist: is the Data API the right fit for your situation?\n\n- [ ] You need real-time (not batch\u002Fovernight) data flow between FileMaker and another system\n- [ ] The other system can make HTTP requests (which is true of almost anything built after 2015)\n- [ ] Your FileMaker file is hosted on FileMaker Server or FileMaker Cloud\n- [ ] You're comfortable building and maintaining dedicated API layouts, separate from your day-to-day working layouts\n- [ ] You have (or can get) someone who understands both FileMaker scripting and basic REST\u002FJSON concepts to build and maintain the integration\n\nIf most of these are true, the Data API is very likely your best option. If you need FileMaker to be the one calling out, or you're integrating with an SQL reporting tool, look at `Insert from URL` scripting or ODBC instead.\n\n## FAQ\n\n**Does the FileMaker Data API cost extra?**\nIt's included with FileMaker Server and FileMaker Cloud licensing — there's no separate fee for the API itself, but your Claris hosting plan may have usage-based limits worth checking.\n\n**Can I use the Data API with FileMaker Pro only, without a server?**\nNo. The Data API is served by FileMaker Server or FileMaker Cloud. A file open only in FileMaker Pro on a desktop cannot answer API requests.\n\n**Is the Data API secure enough for production use?**\nYes, when set up properly: use HTTPS (enforced by default), scope access through dedicated layouts and privilege sets, and avoid exposing admin-level accounts to external systems.\n\n**Can the Data API run FileMaker scripts, not just move data?**\nYes — it can trigger scripts on the server, which is often how teams combine the simplicity of a REST call with FileMaker's existing business logic, instead of duplicating that logic in the external system.\n\nIf you're weighing whether the Data API, a custom connector, or a broader integration strategy is the right move for your specific systems, that's exactly the kind of question Loggix maps out with clients before writing a single line of code — sometimes the answer is a lean API layout on top of your existing FileMaker system, sometimes it's a small custom web app, and sometimes it's adding an AI layer on top of data that's already there. Either way, understanding what the Data API can and can't do is the first step to making that call with confidence.","\u003Cp>You've got a FileMaker system running your orders, inventory, or client records — and now someone wants it to talk to your webshop, your accounting package, or a custom mobile app. The old answer used to be "export a CSV and import it somewhere else, on a schedule, and hope nobody edits the file in between." That's slow, error-prone, and it means your data is never quite in sync. The FileMaker Data API solves exactly this problem: it lets other software read from and write to your FileMaker system directly, in real time, without anyone touching an export button.\u003C\u002Fp>\n\u003Cp>This article explains what the FileMaker Data API actually is, how it works under the hood, where it fits next to other FileMaker connection methods, and what to watch out for when you build on it.\u003C\u002Fp>\n\u003Ch2>What exactly is the FileMaker Data API?\u003C\u002Fh2>\n\u003Cp>The FileMaker Data API is a REST API that Claris (the company behind FileMaker) built directly into FileMaker Server and FileMaker Cloud. "REST" just means it speaks the same language almost every modern web service, app, and integration platform already understands: HTTP requests and JSON responses.\u003C\u002Fp>\n\u003Cp>In practice, that means any system capable of making an HTTP call — a webshop on Shopify or WooCommerce, a Node.js script, a Python job, an iPaaS tool like Make or Zapier, or a custom web app — can:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Log in and get a session token\u003C\u002Fli>\n\u003Cli>Find records (with search criteria, sorting, and pagination)\u003C\u002Fli>\n\u003Cli>Create new records\u003C\u002Fli>\n\u003Cli>Edit existing records\u003C\u002Fli>\n\u003Cli>Delete records\u003C\u002Fli>\n\u003Cli>Upload or download container data (files, images, PDFs)\u003C\u002Fli>\n\u003Cli>Run FileMaker scripts remotely, and even trigger scripts on record events\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>No plugin, no middleware layer required on the FileMaker side — it's built into the platform itself and switched on per database file.\u003C\u002Fp>\n\u003Ch2>How does it actually work, step by step?\u003C\u002Fh2>\n\u003Cp>Here's what a real integration looks like in practice, using an order sync as an example:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Authenticate.\u003C\u002Fstrong> The external system sends a request to \u003Ccode>\u002Ffmi\u002Fdata\u002Fv1\u002Fdatabases\u002FYourFile\u002Fsessions\u003C\u002Fcode> with a username and password (or an OAuth token). FileMaker Server returns a session token.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Address a layout.\u003C\u002Fstrong> The Data API always works through a FileMaker layout — not directly on a table. So you typically build a dedicated API layout that exposes exactly the fields you want to expose, nothing more.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Send the request.\u003C\u002Fstrong> For a new order, that's a POST request to the records endpoint for that layout, with the order data as JSON in the body.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>FileMaker validates and writes.\u003C\u002Fstrong> Any validation rules, auto-enter calculations, and scripts triggered by that layout still run — the Data API doesn't bypass your business logic.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Get a response back.\u003C\u002Fstrong> FileMaker returns the new record ID and any field data you asked for, as JSON.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Close the session.\u003C\u002Fstrong> Tokens expire after 15 minutes of inactivity by default, so long-running integrations need to handle re-authentication.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>A concrete example: a Loggix client running a wholesale operation had orders coming in through a web portal built in a separate framework. Instead of writing that portal's orders to its own database and syncing overnight, the portal calls the FileMaker Data API the moment a customer submits an order. The order appears in FileMaker's order queue within a second, stock gets reserved by the existing FileMaker script, and the warehouse team sees it before the customer's confirmation email even arrives.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F252?w=700&f=webp\" alt=\"external app sending JSON request to FileMaker Server, response returning\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>How is this different from ODBC, XML, or the old PHP API?\u003C\u002Fh2>\n\u003Cp>FileMaker has had several ways to connect to the outside world over the years, and it's worth knowing why the Data API generally wins now:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Method\u003C\u002Fth>\n\u003Cth>Good for\u003C\u002Fth>\n\u003Cth>Downside\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>\u003Cstrong>ODBC\u002FJDBC\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>SQL-style queries from BI tools, reporting\u003C\u002Ftd>\n\u003Ctd>Read-heavy, clunky for writes, connection pooling issues at scale\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>XML\u002FPHP API\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>Legacy web publishing\u003C\u002Ftd>\n\u003Ctd>Deprecated by Claris, no longer actively developed\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>FileMaker Data API (REST)\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>Modern app-to-app integration, mobile apps, webshops\u003C\u002Ftd>\n\u003Ctd>Requires FileMaker Server\u002FCloud (not available on FileMaker Pro alone)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Custom plugins (e.g. for direct API calls out)\u003C\u002Fstrong>\u003C\u002Ftd>\n\u003Ctd>FileMaker calling \u003Cem>out\u003C\u002Fem> to other services\u003C\u002Ftd>\n\u003Ctd>Different direction — this is FileMaker as the client, not the server\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>The key distinction: the Data API turns FileMaker itself into an API \u003Cem>server\u003C\u002Fem> — other systems call in. If you instead need FileMaker to call \u003Cem>out\u003C\u002Fem> to another service (say, pushing an invoice to an accounting API), that's usually done with FileMaker's built-in \u003Ccode>Insert from URL\u003C\u002Fcode> script step or a plugin, which is a related but separate topic covered in our broader guide on \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-connect-filemaker-to-modern-applications-and-services\">how to connect FileMaker to modern applications and services\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>What can you actually build with it?\u003C\u002Fh2>\n\u003Cp>Some real-world patterns we see repeatedly:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Customer-facing portals.\u003C\u002Fstrong> A web or mobile front-end where customers view invoices, submit requests, or track orders — while the actual data and business logic stay in FileMaker.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>E-commerce sync.\u003C\u002Fstrong> Orders placed on a webshop flow into FileMaker automatically, and stock levels update back on the webshop after each sale.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Mobile field apps.\u003C\u002Fstrong> Technicians fill in a native or web app on-site; the Data API pushes that data straight into the FileMaker system used by the back office.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>AI-assisted workflows.\u003C\u002Fstrong> A chatbot or AI agent (something we've built with tools like Klai) queries FileMaker through the Data API to answer questions like "how many units of product X do we have left?" or to log a new lead without a human touching FileMaker directly.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Modern web forms.\u003C\u002Fstrong> Tools like FmBetterforms generate clean, mobile-friendly web forms that submit straight into FileMaker via the Data API — useful when the native FileMaker WebDirect interface feels too heavy or too clunky for a public-facing form.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>What are the gotchas people run into?\u003C\u002Fh2>\n\u003Cp>Things that catch teams off guard the first time they build on the Data API:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cp>\u003Cstrong>You need FileMaker Server or Cloud.\u003C\u002Fstrong> A solo FileMaker Pro file on someone's laptop can't serve the Data API — it has to be hosted.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\u003Cp>\u003Cstrong>Licensing and enabling it.\u003C\u002Fstrong> The Data API must be explicitly enabled per file in FileMaker Server's admin console, and depending on your Claris licensing, API calls may count against usage limits.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\u003Cp>\u003Cstrong>Layouts are your access control.\u003C\u002Fstrong> Because every request goes through a layout, whatever fields are on that layout are exposed. Build dedicated, minimal API layouts — don't just point external calls at your main data-entry layout.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\u003Cp>\u003Cstrong>Session token expiry.\u003C\u002Fstrong> Long-running scripts or slow integrations need retry logic for expired tokens, or they'll silently fail.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\u003Cp>\u003Cstrong>No native rate limiting or throttling.\u003C\u002Fstrong> If a badly written script hammers the API, your FileMaker Server can slow down for everyone else using the file at the same time. Build sensible batching and delays into any bulk sync.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\u003Cp>\u003Cstrong>Error handling is your job.\u003C\u002Fstrong> The API returns error codes, but it won't tell you \u003Cem>why\u003C\u002Fem> a webshop order failed to map to a customer record — that logic has to live in your integration layer.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Checklist: is the Data API the right fit for your situation?\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> You need real-time (not batch\u002Fovernight) data flow between FileMaker and another system\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> The other system can make HTTP requests (which is true of almost anything built after 2015)\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Your FileMaker file is hosted on FileMaker Server or FileMaker Cloud\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> You're comfortable building and maintaining dedicated API layouts, separate from your day-to-day working layouts\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> You have (or can get) someone who understands both FileMaker scripting and basic REST\u002FJSON concepts to build and maintain the integration\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>If most of these are true, the Data API is very likely your best option. If you need FileMaker to be the one calling out, or you're integrating with an SQL reporting tool, look at \u003Ccode>Insert from URL\u003C\u002Fcode> scripting or ODBC instead.\u003C\u002Fp>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Does the FileMaker Data API cost extra?\u003C\u002Fstrong>\nIt's included with FileMaker Server and FileMaker Cloud licensing — there's no separate fee for the API itself, but your Claris hosting plan may have usage-based limits worth checking.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can I use the Data API with FileMaker Pro only, without a server?\u003C\u002Fstrong>\nNo. The Data API is served by FileMaker Server or FileMaker Cloud. A file open only in FileMaker Pro on a desktop cannot answer API requests.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is the Data API secure enough for production use?\u003C\u002Fstrong>\nYes, when set up properly: use HTTPS (enforced by default), scope access through dedicated layouts and privilege sets, and avoid exposing admin-level accounts to external systems.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can the Data API run FileMaker scripts, not just move data?\u003C\u002Fstrong>\nYes — it can trigger scripts on the server, which is often how teams combine the simplicity of a REST call with FileMaker's existing business logic, instead of duplicating that logic in the external system.\u003C\u002Fp>\n\u003Cp>If you're weighing whether the Data API, a custom connector, or a broader integration strategy is the right move for your specific systems, that's exactly the kind of question Loggix maps out with clients before writing a single line of code — sometimes the answer is a lean API layout on top of your existing FileMaker system, sometimes it's a small custom web app, and sometimes it's adding an AI layer on top of data that's already there. Either way, understanding what the Data API can and can't do is the first step to making that call with confidence.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901677000,[19,20,21,22,23,24],"FileMaker Data API","FileMaker integration","REST API","Claris","system connectivity","API connectors","\u002Fapi\u002Fknowledge\u002Fimage\u002F384\u002F?v=492dc519b58d",false,"",null,{"title":30,"slug":31},"FileMaker and Claris","filemaker-and-claris",{"title":33,"slug":34},"How to connect FileMaker to modern applications and services","how-to-connect-filemaker-to-modern-applications-and-services"]