How to connect Claude or another AI assistant to FileMaker

Your support team still opens five different FileMaker layouts to answer one customer question. Your ops manager wants a plain-language summary of today's orders instead of scrolling through a found set. Someone on the floor keeps asking, "can't the system just tell me what changed since yesterday?" — and the honest answer, in a stock FileMaker system, is no. FileMaker is excellent at structured data, but it has no built-in way to reason over that data in natural language. That's exactly the gap tools like Claude, ChatGPT, or other large language model (LLM) assistants are built to fill.

This article walks through how those two worlds actually get wired together: the real connection methods, where each one breaks down in practice, and a step-by-step path to a working setup.

Why would you connect an AI assistant to FileMaker in the first place?

Most teams don't wake up wanting "AI in FileMaker" as a goal in itself. They run into one of a few concrete problems:

• A customer service rep needs a plain-English answer ("which open invoices does this client have, and are any overdue?") without writing a find request.
• A manager wants a daily summary of production records, written like a person would write it, not a spreadsheet export.
• A sales team wants to draft a follow-up email based on a contact's order history, without retyping that history into ChatGPT by hand.
• A developer wants FileMaker to auto-tag, categorize, or summarize incoming records (support tickets, invoices, scanned documents) as they're created.

Each of these is really the same underlying need: let a language model read (and sometimes write) FileMaker data, on demand, inside the workflow people already use.

What are the real ways to connect Claude (or another AI assistant) to FileMaker?

There are four practical patterns in production use today. They're not mutually exclusive — most mature setups end up combining two of them.

1. FileMaker calls the AI assistant's API directly

This is the most common starting point. Claude, OpenAI, and most other LLM providers expose a REST API. FileMaker's Insert from URL script step (available since FileMaker 17, and much easier to use since the JSON functions landed in FileMaker 16+) can POST a prompt to that API and receive a JSON response back.

A typical script looks like this in plain terms:

1. Build a JSON payload containing the prompt (e.g. "Summarize this customer's last 5 support tickets: [ticket text]").
2. Use Insert from URL with the cURL options set to include your API key in the header and the JSON body as the payload.
3. Parse the JSON response with JSONGetElement to pull out the assistant's reply.
4. Write that reply into a field, show it in a popover, or trigger a follow-up action.

This pattern works well for one-off, on-demand requests: "summarize this record," "draft a reply to this email," "classify this ticket." It's simple, it doesn't require a middleware server, and it keeps the AI call inside the FileMaker script engine.

The catch: Insert from URL is synchronous by default, so a slow AI response can freeze the layout for the user unless you run it via Perform Script on Server or a background process. For anything longer than a couple of seconds — which most LLM completions are — plan for that from day one.

2. A middleware layer brokers the connection

For anything beyond simple one-shot prompts — multi-step reasoning, function calling, tool use, or connecting Claude to several systems at once (FileMaker plus a mail server plus a CRM) — a thin middleware layer pays off. This is typically a small web service (Node.js, PHP, or a low-code tool like n8n or Make) that sits between FileMaker and the AI provider.

FileMaker calls the middleware via the Data API or a webhook; the middleware calls Claude's API (potentially with tool-use/function-calling enabled so Claude can decide when to query FileMaker); the middleware writes results back into FileMaker via the Data API.

This is where Anthropic's Model Context Protocol (MCP) becomes relevant. MCP is designed exactly for this scenario: it lets an AI assistant discover and call external "tools" (like "get customer record," "create invoice," "search open orders") through a standard interface, rather than you hand-coding every possible prompt-to-action mapping. In practice, teams build a small MCP server that wraps FileMaker's Data API endpoints as callable tools, then Claude Desktop or Claude's API can call those tools directly when a user asks something that requires FileMaker data.

3. FileMaker exposes data via the Data API, and the AI assistant (or its host app) queries it

Rather than FileMaker calling out, this flips the direction: FileMaker Server's REST-based Data API is turned on, and the AI assistant (through a custom GPT, a Claude tool, or a middleware script) queries FileMaker directly for records, performs finds, and creates or edits records.

This is the right approach when the AI assistant needs broad, flexible access to your data model — for example, a support chatbot that needs to look up any customer, any order, any invoice, on demand, rather than being fed one pre-selected record.

Gotcha to plan for: the Data API requires a FileMaker Server (or Claris Cloud) license with API access enabled, and every request needs a session token that expires — your integration needs to handle token refresh gracefully, or it will silently fail after a period of inactivity.

4. Third-party connector or low-code automation tools

Tools like n8n, Zapier (with custom FileMaker connectors), or Claris Connect-style platforms can sit between FileMaker and an AI provider without you writing a middleware server from scratch. This is often the fastest path to a working proof of concept, and it's a reasonable permanent solution for lower-volume, non-critical workflows. It becomes a bottleneck once you need custom error handling, high request volumes, or tight control over latency and cost — at that point, most teams migrate to a purpose-built middleware layer.

What should you actually build first?

Don't start with "connect Claude to FileMaker" as the project. Start with one narrow, real use case and prove it end to end. A pattern that works well in practice:

1. Pick one workflow with a clear before/after. Example: "When a support ticket is created, generate a suggested first-response draft."
2. Build the FileMaker side first, with a fake/static response. Get the button, the field, the popover, and the script logic working before any AI is involved. This isolates FileMaker bugs from AI bugs.
3. Wire in the real API call using Insert from URL, run via Perform Script on Server if the layout shouldn't freeze.
4. Add logging. Every AI call should write its prompt, response, timestamp, and any error to a log table. When (not if) the AI gives a strange answer, you need to see exactly what was sent.
5. Add guardrails. Cap prompt length, set a timeout, and decide what happens on failure (retry once, show a fallback message, notify an admin) — don't let a hung API call block a user's workflow.
6. Only then generalize. Once one use case works reliably, the second and third use case are usually just new prompts against the same plumbing.

What goes wrong in real Claude-FileMaker integrations?

A few failure patterns show up again and again:

• Sending too much context. A common early mistake is dumping an entire found set (hundreds of records) into a single prompt because "more context is better." It's slower, costs more per call, and often produces vaguer answers than a tightly scoped, well-labeled subset of fields.
• No token/session handling for the Data API. Sessions expire; if your script doesn't detect a 401 and re-authenticate, an integration that worked yesterday quietly stops working today.
• Blocking the UI. Running Insert from URL on a local script tied to a button, on a layout the user is actively working in, means the whole client waits on the AI provider's response time — which can be 3-15 seconds for a substantial completion.
• Treating the AI's output as ground truth. An LLM summarizing invoice data can hallucinate a total that doesn't match the actual field values. Always show the AI-generated text as a draft or suggestion next to the real FileMaker data, not as a replacement for it, in anything financial or customer-facing.
• No cost visibility. API calls to Claude or GPT models are billed per token. Without logging token usage per call, it's easy to discover a runaway script (e.g. one firing on every record in an import of 10,000 rows) only after the invoice arrives.

Do you need FileMaker Server, or can this run on FileMaker Pro alone?

Outbound calls (Insert from URL from FileMaker calling out to Claude's API) work from FileMaker Pro on a single machine — no server required, though Perform Script on Server needs FileMaker Server if you want the call to run server-side rather than freezing the client.

Inbound calls (an AI assistant or middleware querying FileMaker's Data API) require FileMaker Server or Claris Cloud, since the Data API is a server-side feature.

FAQ: connecting Claude or another AI assistant to FileMaker

Does this only work with Claude, or also ChatGPT and other models? The pattern is the same for any provider with a REST API — Claude, OpenAI's GPT models, Google's Gemini, or a self-hosted open-source model. The FileMaker-side plumbing (Insert from URL, JSON parsing, Data API) doesn't change; only the request format and the specific API key differ.

Is Claude's Model Context Protocol (MCP) required to do this? No. MCP is one route — a well-designed one for multi-tool, multi-step scenarios — but plenty of working integrations use nothing more than Insert from URL and a JSON parse for simple, single-purpose prompts. Start with the simplest approach that solves your actual use case.

Can the AI assistant write back into FileMaker, not just read from it? Yes, via the Data API (create/edit record endpoints) or, in the FileMaker-calls-out direction, by having the script take the AI's response and use Set Field / New Record to write it. Always validate AI-generated data before writing it to a system of record — never write straight through without a check.

How do you keep this secure? Store API keys outside of layouts and scripts where possible (a dedicated, access-restricted table or the Data API's OAuth flow), restrict which FileMaker accounts can trigger AI-calling scripts, and never send personally identifiable or sensitive data to an external AI provider unless your data processing agreement and the provider's data retention policy explicitly permit it.

What does this cost to run? Three cost centers: the AI provider's per-token API fees, FileMaker Server hosting if you're exposing the Data API, and the development time to build and maintain the middleware/scripts. For most single-workflow use cases (one summarization task, one classification task), token costs are modest — the bigger cost is usually the integration engineering, done once.

A quick checklist before you start

• One specific workflow identified, with a clear "before" and "after"
• Decision made: outbound call (FileMaker → AI), inbound call (AI → FileMaker Data API), or both
• API key obtained and stored securely, not hardcoded in a script
• Long-running calls routed through Perform Script on Server or a background process
• Logging in place for every prompt, response, and error
• A fallback behavior defined for timeouts or API errors
• AI output clearly labeled as a draft/suggestion wherever it touches financial or customer-facing data
• Token/session refresh handled if using the Data API

Connecting an AI assistant to FileMaker isn't a single feature you switch on — it's an integration project with its own architecture decisions, failure modes, and security considerations, much like any other system-to-system connector. If you're weighing whether to build this yourself, extend an existing FileMaker system with an AI-assisted workflow, or design the middleware layer that lets Claude or another assistant safely read and write your data, that's exactly the kind of custom FileMaker development and API integration work Loggix does — worth a conversation before you write the first script.