canonical: https://jentic.com/apis/help.claris.com

# Claris FileMaker APIs

Claris FileMaker is a custom application platform whose hosted solutions on FileMaker Server and FileMaker Cloud are reachable through three REST interfaces. The FileMaker Data API handles record-level work: creating, editing, deleting, and finding records, uploading to container fields, and running FileMaker scripts. The FileMaker OData API exposes the same tables as OData 4.01 entity sets for tools that already speak OData, such as Power BI and Excel. The FileMaker Admin API manages the server itself: opening and closing databases, messaging and disconnecting clients, and running schedules. Jentic publishes the only OpenAPI specifications for these APIs, keeping them validated and agent-ready.

## For AI agents

An agent can read, write, and find records in a FileMaker solution, query the same tables through OData for BI-shaped tools, and administer the underlying FileMaker Server by opening databases, messaging clients, and running scheduled backups.

## Scope

Use for: Reading and writing records in a hosted FileMaker solution, querying those tables via OData, and administering the FileMaker Server or FileMaker Cloud host that serves them

Not supported:
- FileMaker Pro scripting
- layout or schema design
- OData container uploads
- public rate-limit tables
- webhooks or push events

## APIs

| API | Category | Endpoints | Description |
| --- | --- | --- | --- |
| Claris FileMaker Admin API | developer-tools | 22 | Administer FileMaker Server and FileMaker Cloud - open and close databases, message connected clients, manage schedules, and inspect server status - through a JSON REST API. |
| Claris FileMaker Data API | storage | 13 | Read, create, edit, delete, and find FileMaker records, upload to container fields, and run FileMaker scripts via a JSON REST API. |
| Claris FileMaker OData API | storage | 7 | Query FileMaker tables as OData entity sets - list, filter, and update records using the OData 4.01 standard. |

## Which API to use

| Need | API | Why |
| --- | --- | --- |
| Create, edit, delete, and find records, upload files, or run FileMaker scripts | filemaker-data-api | FileMaker-native JSON record API with find requests, container uploads, and script execution |
| Query the same tables from an OData-aware tool like Power BI or Excel | filemaker-odata-api | Exposes tables as OData 4.01 entity sets with $filter and $select, no FileMaker-specific find syntax |
| Open or close databases, message or disconnect clients, or manage schedules | filemaker-admin-api | Server and database lifecycle administration rather than record access |

## Cross-API use cases

### Safe maintenance window with live client notice

An agent finds records due for a batch update through the Data API, then uses the Admin API to message connected clients and close the database before the write runs and reopen it afterward. This keeps record changes and server state coordinated during a maintenance window.

Example prompt: GET /clients and POST a maintenance notice via the Admin API, PATCH the database closed, run record edits with the Data API, then reopen the database.

### BI dashboard with backup verification

An analyst pulls a filtered slice of a FileMaker table into Power BI through the OData API while an agent confirms the nightly backup ran through the Admin API schedules endpoints, so reporting only runs against a database that was backed up. This pairs live querying with server-side assurance.

Example prompt: GET /schedules/{scheduleId} via the Admin API to confirm the backup, then GET /{database}/{tableName} with an OData $filter for the report.

### Reconcile FileMaker-native and OData record views

An agent writes a new record with the Data API using FileMaker find and container logic, then reads it back through the OData API by primary key so an OData-shaped downstream tool sees the same row. This lets teams mix FileMaker-native writes with standards-based reads.

Example prompt: POST a record via the Data API layout endpoint, then GET /{database}/{tableName}({primaryKey}) via the OData API to confirm the same row.

## Why Jentic

- **Setup:** Wiring the FileMaker APIs by hand means learning each auth flow, carrying short-lived session or bearer tokens, and pointing every call at your own FileMaker host. Through Jentic you install Jentic One once, add the Data, OData, or Admin API from the Jentic directory, store the credentials once, and your agent calls them.
- **Permission scoping:** Each FileMaker API puts the database, layout or table, and record or client id in the URL path, so your own rules can pin an agent to one database and layout and to specific operations. Destructive calls such as deleting records, disconnecting clients, or closing a database are only available if you add them.
- **Credential handling:** Your FileMaker admin and database credentials, along with the session and bearer tokens they produce, are stored encrypted by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search the Jentic directory by intent such as 'find FileMaker records', 'query a FileMaker table via OData', or 'open a hosted database', and Jentic returns the matching operation with its input schema so the agent calls the right endpoint across all three APIs without reading the FileMaker docs.

## Related vendors

- **Airtable** — Hosted database with a REST API and rich field types, an alternative for new builds without an on-prem FileMaker requirement
- **MongoDB Atlas** — Managed database with both data and admin APIs, an alternative when the workload is document-store rather than a FileMaker solution
- **SmartSuite** — Work-management database platform with a REST API, adjacent for teams weighing a hosted low-code database against FileMaker

## FAQ

### Why does Jentic publish these FileMaker APIs?

Claris does not publish OpenAPI specifications for FileMaker. Jentic generates and maintains validated OpenAPI-shaped specs for the Data, OData, and Admin APIs so agents and developers can call them through structured tooling that is kept up to date against the live APIs.

### How do the three FileMaker APIs differ?

The Data API is the FileMaker-native record surface with find requests, container uploads, and script execution. The OData API exposes the same tables as OData 4.01 entity sets for tools that already speak OData. The Admin API manages the server: databases, clients, and schedules. They serve the same hosted solution from different angles.

### Do I need one set of credentials or several?

Each API authenticates against the same FileMaker Server or FileMaker Cloud host, so the underlying account is shared, but the Admin API uses admin-level credentials for server operations while the Data and OData APIs use database-level credentials. You can scope each set to the operations the agent actually needs.

### Which FileMaker API should an agent use for reporting?

Use the OData API when the consuming tool is OData-aware, such as Power BI, Excel, or Tableau, because it exposes tables as entity sets with $filter and $select. Use the Data API's find requests when you need FileMaker-native query logic or paged extracts for a data warehouse.

### Can these APIs work with both FileMaker Server and FileMaker Cloud?

Yes. All three APIs target a FileMaker host and work against both FileMaker Server and FileMaker Cloud deployments. The host address changes but the operations are the same, so an agent can point the same workflow at either environment.

### Are container uploads and scripts available across all three APIs?

No. Container uploads and FileMaker script execution are only on the Data API. The OData API is limited to tabular record access and CRUD by primary key, and the Admin API handles server, database, client, and schedule operations rather than record content.