Data API or OData? The FileMaker API choice that actually matters.
There is no magic winner here. Both are good APIs, but they are good at different jobs. The FileMaker Data API is usually the better fit when your app needs to behave like FileMaker. OData is usually the better fit when another system wants clean, standard access to tables and fields.
Pick the API that matches the job, not the one with the cooler name.
If you are building a React app, a customer portal, a mobile app, or something that needs FileMaker scripts, portals, value lists, and layout-driven data, start with the FileMaker Data API. If you are connecting a reporting tool, middleware, BI platform, or another developer's standard REST client directly to tables, OData may be the cleaner choice.
Choose Data API when...
- You want FileMaker layouts to control what the app sees.
- You need portal data, value lists, globals, or FileMaker scripts.
- You have FileMaker business logic you do not want to rebuild in JavaScript.
- You are building a custom web or mobile app around a FileMaker solution.
Choose OData when...
- You need a standards-based table and field API.
- You want familiar query options such as
$select,$filter, and$orderby. - You are connecting reporting, integration, or data tools that already understand OData.
- You want batch requests, or you need controlled schema work through an API.
The one that understands FileMaker's world
The Data API is FileMaker-aware. Requests are based on layouts, records have FileMaker recordId and modId values, and a layout can return field data, portals, and value lists in one response. It can also run FileMaker scripts and set global fields. That makes it a very natural fit for an app that is an extension of an existing FileMaker system.
GET /fmi/data/vLatest/databases/YourDatabase/layouts/Web_Contacts/records/324
Authorization: Bearer session-tokenYou choose a layout for the request. That can be helpful because it creates a purpose-built API view of the data.
You can use FileMaker scripts for validation, workflows, exports, notifications, and other business rules.
Related data can come back as portal data, instead of having to make every relationship from scratch in your app.
What I like about it
- It respects the way many FileMaker solutions are already built.
- A good API layout can expose only what an app needs, which is great for safety and maintenance.
- It is very practical for FileMaker forms, dashboards, customer portals, and mobile apps.
- It has a session token workflow, so your app does not send a database password on every request.
What can be annoying
- Layouts become part of your API contract. Rename a layout or remove a field and your app can break.
- Developers coming from normal REST APIs sometimes find the layout-first approach confusing at first.
- It is FileMaker-specific, which is a strength in a FileMaker project but less portable outside of one.
The more standard, table-first option
OData is an industry-standard REST API. With FileMaker's OData API, you work with tables, fields, primary keys, metadata, and standard query options. There are no layouts required for a basic OData call. That can feel much more familiar to a web developer or an integration platform that has never heard of a FileMaker layout.
GET /fmi/odata/v4/YourDatabase/Contacts?$select=Name,Email&$filter=Status eq 'Active'
Authorization: Basic base64-account-and-passwordFileMaker supports OData at the intermediate level, with some exceptions. It can retrieve metadata, create, edit and delete records, filter and sort data, run scripts, upload containers, run batch requests, and it even supports certain schema changes. That does not mean you should hand schema rights to every integration. Please don't do that on a production system without some thought.
What I like about it
- The URL patterns and query options are recognizable to people who know REST and OData.
- It is very nice for direct data work, reporting, middleware, and integrations.
- It does not depend on layouts, so your API is less tied to FileMaker's user interface.
- Batch requests can reduce round trips when you have a few related operations to perform.
What to watch for
- OData exposes tables and fields more directly, so you need to be intentional about privilege sets and what accounts can see or edit.
- It does not give you the Data API's layout and portal model. You may need to compose related data in your own service.
- Some standard OData features are not supported, including
$searchand some advanced filtering functions. - On FileMaker Server, OData uses standard Basic authentication over HTTPS. Never put those credentials in browser code.
Same database. Different point of view.
Data API thinks in FileMaker terms
Starting point: a layout.
Identity: record ID and modification ID.
Related data: portals and layout context.
Best for: a FileMaker-driven application where your layouts and scripts already contain useful logic.
OData thinks in data terms
Starting point: a table or entity set.
Identity: a primary key, or FileMaker's ROWID when no primary key is set.
Related data: queries and a service layer you design.
Best for: integrations that want predictable, standards-based data access.
Data API is usually the app API. OData is usually the data integration API.
That is not a law, but it is a pretty useful starting point. The final answer depends on your existing solution, your security needs, how much FileMaker logic is already there, and who has to maintain the thing six months from now.
See examplesHow this usually plays out
Customer portal built in React
Usually Data API. Create API layouts for customers, orders, invoices, and support requests. Let FileMaker scripts handle the things FileMaker already handles well: validation, notifications, PDFs, and workflow changes.
Power BI, reporting, or a data warehouse
Often OData. The table and field model is straightforward for external tools. Give the integration account only the access it needs, and keep production write access off unless there is a real reason for it.
Website lead form to FileMaker
Either can work. Data API is nice when a FileMaker script needs to route the lead, create related records, and send an email. OData is fine for a simple, controlled insert through a server-side integration.
QuickBooks, Salesforce, Shopify, or another API
Usually depends on the workflow. If FileMaker is the place where business rules happen, use Data API and scripts. If you mostly need to move normalized records back and forth, OData can be very clean.
Do not let the browser talk directly to your FileMaker server with real credentials.
The React app in a visitor's browser is not a safe place for a FileMaker account password, a Data API session token, or an OData Authorization header. People can inspect browser traffic and bundled JavaScript. Keep the FileMaker call on a server-side service, such as a Node/TypeScript API route, serverless function, or secure middleware application.
Browser / React app
|
v
Your secure server-side API
|
v
FileMaker Data API or OData.env file that gets built for the browser.For Data API, enable the fmrest extended privilege on the integration account. For OData, enable fmodata. You must also enable the relevant API in FileMaker Server or FileMaker Cloud. Both should be used over HTTPS.
Build the smallest safe test first
- Make a copy or development version of the FileMaker file. Do not learn on the live customer database if you can avoid it.
- Create a dedicated API account with limited access.
- Enable only
fmrestorfmodata, based on the API you are testing. - Turn on that API in FileMaker Server or FileMaker Cloud Admin Console.
- Make one read-only request from a server-side test. A single customer or product record is plenty.
- Log what happened, then add create and update operations only after the read test works.
- Put the code in Git, keep secrets in a real local
.envfile, and commit only.env.example.
For current setup details and the exact endpoints, use the official Claris documentation. The Data API and OData API continue to evolve, and the docs are the source of truth for server versions and supported features.
Claris FileMaker Data API Guide | Claris FileMaker OData API Guide
We would be glad to hear about your project.
RGC Data LLC works with Claris FileMaker integrations and connected systems. We handle FileMaker database work, web applications, React and TypeScript projects, WordPress, native and cross-platform mobile apps, QuickBooks, Salesforce, and other API-based systems.
If you are not sure how the pieces should fit together, we are happy to listen, talk through the project, and see whether we can be useful.
Request a quote Email Alex
