FileMaker Data API — Building REST Integrations

The FileMaker Data API is a REST interface built into FileMaker Server that lets external applications interact with hosted databases. It enables web apps, mobile apps, and third-party systems to perform CRUD operations, run scripts, and retrieve data — all over HTTPS using standard JSON payloads.

We've used the Data API extensively across our projects, from React frontends that display FileMaker data in real time to backend integrations that synchronise FileMaker with external services. This guide covers the practical patterns we've developed through that experience.

When to Use the Data API

The Data API is the right tool when you need external applications to read or write data in FileMaker. Common scenarios include: building custom web interfaces that aren't constrained by WebDirect's limitations, creating mobile apps that need to sync with FileMaker, integrating FileMaker with other business systems (CRMs, accounting software, e-commerce platforms), and building dashboards or reporting tools that pull live data from FileMaker.

It's not the right tool for everything. If your integration is FileMaker-to-FileMaker, or if you're making outbound calls from FileMaker to external services, Insert from URL is usually simpler. The Data API is specifically for inbound access — external systems reaching into FileMaker.

Authentication Flow

The Data API uses token-based authentication. Before you can make any data requests, you need to obtain a session token by authenticating with a valid FileMaker account.

POST /fmi/data/vLatest/databases/{database}/sessions
Authorization: Basic {base64-encoded credentials}
Content-Type: application/json
Body: {}

The response includes a bearer token:

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

Include this token in the Authorization header of all subsequent requests:

Authorization: Bearer a1b2c3d4e5f6...

Tokens expire after 15 minutes of inactivity. When you're finished, explicitly release the token with a DELETE request to the sessions endpoint. This is important — FileMaker Server has a limited number of concurrent sessions, and orphaned tokens consume that capacity until they expire.

CRUD Operations

The Data API follows RESTful conventions. Each operation maps to an HTTP method and a predictable URL pattern.

Create a Record

POST /fmi/data/vLatest/databases/{database}/layouts/{layout}/records
Authorization: Bearer {token}
Content-Type: application/json

{
  "fieldData": {
    "FirstName": "Jane",
    "LastName": "Smith",
    "Email": "jane@example.com"
  }
}

The response returns the recordId of the newly created record, which you'll need for subsequent update or delete operations.

Read Records

GET /fmi/data/vLatest/databases/{database}/layouts/{layout}/records?_limit=10&_offset=1

You can control pagination with _limit and _offset parameters, and sort results with _sort. The response includes both field data and portal data for each record.

Update a Record

PATCH /fmi/data/vLatest/databases/{database}/layouts/{layout}/records/{recordId}

{
  "fieldData": {
    "Email": "jane.smith@example.com"
  }
}

Only include the fields you want to change. The Data API supports optimistic locking through the modId parameter — if another user has modified the record since you last read it, the update will fail with an error, preventing you from overwriting their changes.

Delete a Record

DELETE /fmi/data/vLatest/databases/{database}/layouts/{layout}/records/{recordId}

Perform a Find

POST /fmi/data/vLatest/databases/{database}/layouts/{layout}/_find

{
  "query": [
    { "Status": "Active", "City": "Glasgow" },
    { "Status": "Active", "City": "Edinburgh" }
  ],
  "sort": [
    { "fieldName": "LastName", "sortOrder": "ascend" }
  ],
  "limit": "50"
}

Multiple objects in the query array act as OR conditions — the example above finds active records in Glasgow or Edinburgh. Fields within a single query object act as AND conditions. This mirrors FileMaker's native find behaviour with multiple find requests.

Running FileMaker Scripts via the API

One of the Data API's most powerful features is the ability to trigger FileMaker scripts. You can run scripts as part of any data operation by including script parameters:

{
  "fieldData": { ... },
  "script": "ProcessNewRecord",
  "script.param": "param-value",
  "script.prerequest": "ValidateAccess",
  "script.prerequest.param": "check-permissions"
}

The API supports three script hooks: script.prerequest runs before the data operation, script.presort runs after the operation but before sorting, and script runs after everything else. This gives you fine-grained control over business logic execution.

Script results are returned in the API response, which means you can use a FileMaker script to perform complex operations — calculations across related tables, conditional logic, integration with plugins — and return the result to the calling application.

Portal Data and Filtering

The Data API returns portal data alongside field data for each record. Portal rows appear under a portalData key, grouped by the portal's layout object name (or the related table occurrence name if no object name is assigned).

You can control which portals are included in the response using the portal parameter, and limit the number of portal rows with _limit.portalObjectName and _offset.portalObjectName.

An important discovery we documented in a previous article on portal filters: portal filters applied on the FileMaker layout are respected by the Data API. The JSON response will only include portal rows that pass the filter, without any additional API parameters. This is a powerful technique for controlling portal data without modifying relationships.

Error Handling Patterns

Every Data API response includes a messages array with a code and message. Code "0" indicates success; anything else is an error. Common errors you'll need to handle:

• 401 — Invalid or expired token. Re-authenticate and retry.
• 404 — Record not found. The record may have been deleted by another user.
• 500 — FileMaker error codes (e.g., 401 = no records match the find criteria). These are returned as HTTP 500 with a FileMaker-specific error code in the response body.
• 952 — Invalid token. Your session has expired.

In production applications, we implement a wrapper function that checks the response code, automatically re-authenticates on token expiry, and retries the original request. This handles the most common failure mode — expired sessions — transparently.

Rate Limiting and Performance

FileMaker Server doesn't impose explicit rate limits on the Data API, but practical limits exist. Each authenticated session consumes server resources, and FileMaker Server has a configurable maximum number of concurrent Data API sessions (default is 500).

For high-traffic web applications, we implement connection pooling on the application server side — maintaining a pool of authenticated sessions and reusing them across requests rather than authenticating and releasing for every API call. This reduces authentication overhead and improves response times.

Layout complexity directly affects API response times. A layout with dozens of fields, multiple portals, and summary calculations will return significantly more data and take longer to process than a streamlined layout. We create dedicated "API layouts" with only the fields needed for each integration, which can reduce response times dramatically.

Real-World Integration Examples

React Frontends. We've built several web applications where a React frontend communicates with FileMaker through the Data API. The React app authenticates once, stores the token, and makes API calls as the user navigates. We use a Node.js middleware layer to handle token management and add application-level caching, which reduces the number of direct API calls to FileMaker Server.

Webhook Receivers. External services (payment processors, form builders, e-commerce platforms) send webhook notifications to a lightweight server that translates them into Data API calls. When a payment completes in Stripe, for example, our webhook handler creates a payment record in FileMaker and triggers a script to update the associated invoice.

Reporting Dashboards. We've connected business intelligence tools to FileMaker using the Data API, pulling live data into dashboards that update automatically. The Data API's find and sort capabilities let us implement server-side filtering, so only relevant data is transferred.

Getting Started

To begin using the Data API, ensure it's enabled in your FileMaker Server admin console under Connectors. Create a FileMaker account with the fmrest extended privilege enabled. Start with simple GET requests to read records, then progress to finds, creates, and script execution as you become comfortable with the patterns.

If you're building a web application, we recommend using a server-side middleware layer (Node.js, Python, PHP) rather than calling the Data API directly from browser JavaScript. This keeps your FileMaker credentials secure, lets you implement caching and connection pooling, and gives you a place to add application logic that doesn't belong in either the frontend or FileMaker.

We've also built a number of open-source tools for working with FileMaker data — including our CSV to JSON converter and MIME type utility — that complement Data API integrations.