What is the FileMaker Data API?

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.

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.

What exactly is the FileMaker Data API?

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.

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:

• Log in and get a session token
• Find records (with search criteria, sorting, and pagination)
• Create new records
• Edit existing records
• Delete records
• Upload or download container data (files, images, PDFs)
• Run FileMaker scripts remotely, and even trigger scripts on record events

No plugin, no middleware layer required on the FileMaker side — it's built into the platform itself and switched on per database file.

How does it actually work, step by step?

Here's what a real integration looks like in practice, using an order sync as an example:

1. Authenticate. The external system sends a request to /fmi/data/v1/databases/YourFile/sessions with a username and password (or an OAuth token). FileMaker Server returns a session token.
2. 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.
3. 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.
4. 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.
5. Get a response back. FileMaker returns the new record ID and any field data you asked for, as JSON.
6. Close the session. Tokens expire after 15 minutes of inactivity by default, so long-running integrations need to handle re-authentication.

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.

How is this different from ODBC, XML, or the old PHP API?

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:

Method	Good for	Downside
ODBC/JDBC	SQL-style queries from BI tools, reporting	Read-heavy, clunky for writes, connection pooling issues at scale
XML/PHP API	Legacy web publishing	Deprecated by Claris, no longer actively developed
FileMaker Data API (REST)	Modern app-to-app integration, mobile apps, webshops	Requires FileMaker Server/Cloud (not available on FileMaker Pro alone)
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

The 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.

What can you actually build with it?

Some real-world patterns we see repeatedly:

• 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.
• E-commerce sync. Orders placed on a webshop flow into FileMaker automatically, and stock levels update back on the webshop after each sale.
• 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.
• 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.
• 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.

What are the gotchas people run into?

Things that catch teams off guard the first time they build on the Data API:

• 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.

• 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.

• 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.

• Session token expiry. Long-running scripts or slow integrations need retry logic for expired tokens, or they'll silently fail.

• 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.

• 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.

Checklist: is the Data API the right fit for your situation?

• You need real-time (not batch/overnight) data flow between FileMaker and another system
• The other system can make HTTP requests (which is true of almost anything built after 2015)
• Your FileMaker file is hosted on FileMaker Server or FileMaker Cloud
• You're comfortable building and maintaining dedicated API layouts, separate from your day-to-day working layouts
• You have (or can get) someone who understands both FileMaker scripting and basic REST/JSON concepts to build and maintain the integration

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 Insert from URL scripting or ODBC instead.

FAQ

Does the FileMaker Data API cost extra? It'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.

Can I use the Data API with FileMaker Pro only, without a server? No. 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.

Is the Data API secure enough for production use? Yes, 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.

Can the Data API run FileMaker scripts, not just move data? Yes — 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.

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.