[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fxnEV6B2IDmZK-HB9eqDURpOmv_18sK7mC59_BhOK3tE":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":25,"hasDownload":26,"fileName":27,"youtubeId":28,"domainCrumb":29,"clusterCrumb":32},"393","107814C7-0AF5-884D-91A1-D0A44A3D0C21","E46BDB0A-2979-1E40-93F7-AC40185848A5","33710AE6-6A9E-F741-A6A4-9DFCC5810440","article","how-to-connect-claude-or-another-ai-assistant-to-filemaker","How to connect Claude or another AI assistant to FileMaker","A practical guide to connecting Claude or another AI assistant to FileMaker, with real integration methods, gotchas, and step-by-step setup guidance.","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.\n\nThis 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.\n\n## Why would you connect an AI assistant to FileMaker in the first place?\n\nMost teams don't wake up wanting \"AI in FileMaker\" as a goal in itself. They run into one of a few concrete problems:\n\n- 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.\n- A manager wants a daily summary of production records, written like a person would write it, not a spreadsheet export.\n- 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.\n- A developer wants FileMaker to auto-tag, categorize, or summarize incoming records (support tickets, invoices, scanned documents) as they're created.\n\nEach 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.\n\n## What are the real ways to connect Claude (or another AI assistant) to FileMaker?\n\nThere are four practical patterns in production use today. They're not mutually exclusive — most mature setups end up combining two of them.\n\n### 1. FileMaker calls the AI assistant's API directly\n\nThis 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.\n\nA typical script looks like this in plain terms:\n\n1. Build a JSON payload containing the prompt (e.g. \"Summarize this customer's last 5 support tickets: [ticket text]\").\n2. Use `Insert from URL` with the cURL options set to include your API key in the header and the JSON body as the payload.\n3. Parse the JSON response with `JSONGetElement` to pull out the assistant's reply.\n4. Write that reply into a field, show it in a popover, or trigger a follow-up action.\n\nThis 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.\n\nThe 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.\n\n### 2. A middleware layer brokers the connection\n\nFor 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.\n\nFileMaker calls the middleware via the Data API or a webhook; the middleware calls Claude's API (potentially with tool-use\u002Ffunction-calling enabled so Claude can decide *when* to query FileMaker); the middleware writes results back into FileMaker via the Data API.\n\nThis 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.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F199?w=700&f=webp\" alt=\"Claude assistant, middleware box, and FileMaker database connected by arrows\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n### 3. FileMaker exposes data via the Data API, and the AI assistant (or its host app) queries it\n\nRather 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.\n\nThis 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.\n\nGotcha 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.\n\n### 4. Third-party connector or low-code automation tools\n\nTools 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.\n\n## What should you actually build first?\n\nDon'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:\n\n1. **Pick one workflow with a clear before\u002Fafter.** Example: \"When a support ticket is created, generate a suggested first-response draft.\"\n2. **Build the FileMaker side first, with a fake\u002Fstatic 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.\n3. **Wire in the real API call** using `Insert from URL`, run via `Perform Script on Server` if the layout shouldn't freeze.\n4. **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.\n5. **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.\n6. **Only then generalize.** Once one use case works reliably, the second and third use case are usually just new prompts against the same plumbing.\n\n## What goes wrong in real Claude-FileMaker integrations?\n\nA few failure patterns show up again and again:\n\n- **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.\n- **No token\u002Fsession 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.\n- **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.\n- **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.\n- **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.\n\n## Do you need FileMaker Server, or can this run on FileMaker Pro alone?\n\nOutbound 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.\n\nInbound 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.\n\n## FAQ: connecting Claude or another AI assistant to FileMaker\n\n**Does this only work with Claude, or also ChatGPT and other models?**\nThe 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.\n\n**Is Claude's Model Context Protocol (MCP) required to do this?**\nNo. 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.\n\n**Can the AI assistant write back into FileMaker, not just read from it?**\nYes, via the Data API (create\u002Fedit record endpoints) or, in the FileMaker-calls-out direction, by having the script take the AI's response and use `Set Field` \u002F `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.\n\n**How do you keep this secure?**\nStore 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.\n\n**What does this cost to run?**\nThree 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\u002Fscripts. 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.\n\n## A quick checklist before you start\n\n- [ ] One specific workflow identified, with a clear \"before\" and \"after\"\n- [ ] Decision made: outbound call (FileMaker → AI), inbound call (AI → FileMaker Data API), or both\n- [ ] API key obtained and stored securely, not hardcoded in a script\n- [ ] Long-running calls routed through `Perform Script on Server` or a background process\n- [ ] Logging in place for every prompt, response, and error\n- [ ] A fallback behavior defined for timeouts or API errors\n- [ ] AI output clearly labeled as a draft\u002Fsuggestion wherever it touches financial or customer-facing data\n- [ ] Token\u002Fsession refresh handled if using the Data API\n\nConnecting 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.","\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2>Why would you connect an AI assistant to FileMaker in the first place?\u003C\u002Fh2>\n\u003Cp>Most teams don't wake up wanting "AI in FileMaker" as a goal in itself. They run into one of a few concrete problems:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>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.\u003C\u002Fli>\n\u003Cli>A manager wants a daily summary of production records, written like a person would write it, not a spreadsheet export.\u003C\u002Fli>\n\u003Cli>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.\u003C\u002Fli>\n\u003Cli>A developer wants FileMaker to auto-tag, categorize, or summarize incoming records (support tickets, invoices, scanned documents) as they're created.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2>What are the real ways to connect Claude (or another AI assistant) to FileMaker?\u003C\u002Fh2>\n\u003Cp>There are four practical patterns in production use today. They're not mutually exclusive — most mature setups end up combining two of them.\u003C\u002Fp>\n\u003Ch3>1. FileMaker calls the AI assistant's API directly\u003C\u002Fh3>\n\u003Cp>This is the most common starting point. Claude, OpenAI, and most other LLM providers expose a REST API. FileMaker's \u003Ccode>Insert from URL\u003C\u002Fcode> 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.\u003C\u002Fp>\n\u003Cp>A typical script looks like this in plain terms:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Build a JSON payload containing the prompt (e.g. "Summarize this customer's last 5 support tickets: [ticket text]").\u003C\u002Fli>\n\u003Cli>Use \u003Ccode>Insert from URL\u003C\u002Fcode> with the cURL options set to include your API key in the header and the JSON body as the payload.\u003C\u002Fli>\n\u003Cli>Parse the JSON response with \u003Ccode>JSONGetElement\u003C\u002Fcode> to pull out the assistant's reply.\u003C\u002Fli>\n\u003Cli>Write that reply into a field, show it in a popover, or trigger a follow-up action.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>The catch: \u003Ccode>Insert from URL\u003C\u002Fcode> is synchronous by default, so a slow AI response can freeze the layout for the user unless you run it via \u003Ccode>Perform Script on Server\u003C\u002Fcode> or a background process. For anything longer than a couple of seconds — which most LLM completions are — plan for that from day one.\u003C\u002Fp>\n\u003Ch3>2. A middleware layer brokers the connection\u003C\u002Fh3>\n\u003Cp>For anything beyond simple one-shot prompts — multi-step reasoning, function calling, tool use, or connecting Claude to \u003Cem>several\u003C\u002Fem> 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.\u003C\u002Fp>\n\u003Cp>FileMaker calls the middleware via the Data API or a webhook; the middleware calls Claude's API (potentially with tool-use\u002Ffunction-calling enabled so Claude can decide \u003Cem>when\u003C\u002Fem> to query FileMaker); the middleware writes results back into FileMaker via the Data API.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F199?w=700&f=webp\" alt=\"Claude assistant, middleware box, and FileMaker database connected by arrows\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch3>3. FileMaker exposes data via the Data API, and the AI assistant (or its host app) queries it\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3>4. Third-party connector or low-code automation tools\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2>What should you actually build first?\u003C\u002Fh2>\n\u003Cp>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:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Pick one workflow with a clear before\u002Fafter.\u003C\u002Fstrong> Example: "When a support ticket is created, generate a suggested first-response draft."\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Build the FileMaker side first, with a fake\u002Fstatic response.\u003C\u002Fstrong> Get the button, the field, the popover, and the script logic working before any AI is involved. This isolates FileMaker bugs from AI bugs.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Wire in the real API call\u003C\u002Fstrong> using \u003Ccode>Insert from URL\u003C\u002Fcode>, run via \u003Ccode>Perform Script on Server\u003C\u002Fcode> if the layout shouldn't freeze.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Add logging.\u003C\u002Fstrong> 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Add guardrails.\u003C\u002Fstrong> 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Only then generalize.\u003C\u002Fstrong> Once one use case works reliably, the second and third use case are usually just new prompts against the same plumbing.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>What goes wrong in real Claude-FileMaker integrations?\u003C\u002Fh2>\n\u003Cp>A few failure patterns show up again and again:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Sending too much context.\u003C\u002Fstrong> 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>No token\u002Fsession handling for the Data API.\u003C\u002Fstrong> Sessions expire; if your script doesn't detect a 401 and re-authenticate, an integration that worked yesterday quietly stops working today.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Blocking the UI.\u003C\u002Fstrong> Running \u003Ccode>Insert from URL\u003C\u002Fcode> 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Treating the AI's output as ground truth.\u003C\u002Fstrong> 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 \u003Cem>draft\u003C\u002Fem> or \u003Cem>suggestion\u003C\u002Fem> next to the real FileMaker data, not as a replacement for it, in anything financial or customer-facing.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>No cost visibility.\u003C\u002Fstrong> 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.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Do you need FileMaker Server, or can this run on FileMaker Pro alone?\u003C\u002Fh2>\n\u003Cp>Outbound calls (\u003Ccode>Insert from URL\u003C\u002Fcode> from FileMaker calling out to Claude's API) work from FileMaker Pro on a single machine — no server required, though \u003Ccode>Perform Script on Server\u003C\u002Fcode> needs FileMaker Server if you want the call to run server-side rather than freezing the client.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2>FAQ: connecting Claude or another AI assistant to FileMaker\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Does this only work with Claude, or also ChatGPT and other models?\u003C\u002Fstrong>\nThe 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 (\u003Ccode>Insert from URL\u003C\u002Fcode>, JSON parsing, Data API) doesn't change; only the request format and the specific API key differ.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is Claude's Model Context Protocol (MCP) required to do this?\u003C\u002Fstrong>\nNo. MCP is one route — a well-designed one for multi-tool, multi-step scenarios — but plenty of working integrations use nothing more than \u003Ccode>Insert from URL\u003C\u002Fcode> and a JSON parse for simple, single-purpose prompts. Start with the simplest approach that solves your actual use case.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can the AI assistant write back into FileMaker, not just read from it?\u003C\u002Fstrong>\nYes, via the Data API (create\u002Fedit record endpoints) or, in the FileMaker-calls-out direction, by having the script take the AI's response and use \u003Ccode>Set Field\u003C\u002Fcode> \u002F \u003Ccode>New Record\u003C\u002Fcode> to write it. Always validate AI-generated data before writing it to a system of record — never write straight through without a check.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>How do you keep this secure?\u003C\u002Fstrong>\nStore 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>What does this cost to run?\u003C\u002Fstrong>\nThree 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\u002Fscripts. 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.\u003C\u002Fp>\n\u003Ch2>A quick checklist before you start\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> One specific workflow identified, with a clear "before" and "after"\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Decision made: outbound call (FileMaker → AI), inbound call (AI → FileMaker Data API), or both\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> API key obtained and stored securely, not hardcoded in a script\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Long-running calls routed through \u003Ccode>Perform Script on Server\u003C\u002Fcode> or a background process\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Logging in place for every prompt, response, and error\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> A fallback behavior defined for timeouts or API errors\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> AI output clearly labeled as a draft\u002Fsuggestion wherever it touches financial or customer-facing data\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Token\u002Fsession refresh handled if using the Data API\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901678000,[19,20,21,22,23,24],"FileMaker AI integration","Claude API","FileMaker automation","AI assistant connector","FileMaker Data API","Claris FileMaker","\u002Fapi\u002Fknowledge\u002Fimage\u002F393\u002F?v=05345da5ccf0",false,"",null,{"title":30,"slug":31},"FileMaker and Claris","filemaker-and-claris",{"title":33,"slug":34},"How to connect FileMaker to modern applications and services","how-to-connect-filemaker-to-modern-applications-and-services"]