How to use FileMaker scripts through an API

Your webshop takes an order at 11pm, but the shipping label, stock update, and confirmation email in FileMaker don't happen until someone opens the file the next morning and clicks a button. Or a customer fills in a form on your website, and someone on your team manually re-types that data into FileMaker before anything actually happens with it. If your business logic lives in FileMaker but the trigger for that logic lives somewhere else — a website, an e-commerce platform, a scanning app on a warehouse floor — you have a real integration problem, not just an annoyance.

The good news: FileMaker has supported calling scripts from outside the file for years, and with the Data API and OttoFMS/Claris FileMaker Server webhooks, it's now a solved problem — if you know where the sharp edges are. This article walks through exactly how it works, what it's good for, and what breaks if you skip the planning.

What does it actually mean to "run a FileMaker script through an API"?

Normally, a FileMaker script runs because a user clicks a button, or because a scheduled server script fires on a timer. Running a script "through an API" means an external system — a website, another database, a mobile app, an ERP, a payment provider — sends an HTTP request to FileMaker Server, and that request triggers a script to run, with data attached.

Concretely: a webhook from your payment provider (Stripe, Mollie, Adyen) fires the moment a payment clears. That webhook calls an endpoint on your FileMaker Server. FileMaker Data API receives it, runs a script called "Process Paid Order," passes along the order ID and amount as a script parameter, and the script does the rest — updates the record, generates a PDF invoice, sends a confirmation email. No human ever opens FileMaker for this order.

This is fundamentally different from just reading or writing records through the API (which the Data API also does). Triggering a script means external systems can invoke your actual business logic — validation rules, multi-step processes, calculations you already built inside FileMaker — instead of that logic having to be duplicated somewhere else.

How do you actually set this up?

Here's the practical, step-by-step version of what an implementation looks like:

1. Enable the Data API on FileMaker Server (or Claris FileMaker Cloud) for the relevant file, and create a dedicated API-only account with the minimum privilege set it actually needs — never reuse an admin account for this.
2. Write (or adapt) the script so it's safe to run headless. That means no dialog boxes, no "waiting for user input," and explicit error handling at every step (more on this below).
3. Authenticate — request a session token from the Data API using the account credentials, then include that token in every subsequent request. Tokens expire, so your calling code needs to handle re-authentication gracefully, not just fail silently.
4. Call the script endpoint with a POST request to /fmi/data/vLatest/databases/{database}/layouts/{layout}/script/{scriptName}, passing a script.param value with whatever data the script needs — an order ID, a customer email, a JSON payload.
5. Read the response. The Data API returns the script's result and any error code. Design your script to explicitly Set Script Result with something meaningful (success/failure, a record ID, an error message) — don't leave the calling system guessing.
6. Log everything. Every script run triggered externally should write to a log table: timestamp, parameter received, result, duration. When something goes wrong at 2am, this log is the only thing that tells you what happened.
7. Test failure paths, not just the happy path. What happens if the record already exists? If the external system sends malformed data? If FileMaker Server is mid-backup? Each of these needs a defined behavior, not a crash.

What's the difference between the Data API, OttoFMS, and a custom web viewer trick?

There are three common approaches, and picking the wrong one for your situation is one of the most common mistakes we see:

• Claris FileMaker Data API — the official, supported REST API built into FileMaker Server. Best for most cases: it's stable, documented, and Claris maintains it. Its main limitation is that it's tied to Claris licensing and has some rate/session constraints worth knowing before you scale up.
• OttoFMS — a third-party add-on server that sits alongside FileMaker Server and gives you webhook support, easier script scheduling, and a friendlier way to trigger scripts from external events without polling. Popular for integrations with many small, frequent triggers (e.g. every new Shopify order).
• The old "fmp:// URL" or PSOS (Perform Script On Server) triggered by a plugin — an older pattern, still seen in legacy systems, where a script is triggered by a URL scheme or a scheduled plugin call rather than a proper API request. It works, but it's fragile, hard to secure, and hard to monitor. If you inherited a system built this way, migrating it to the Data API is usually worth the effort — our broader guide on how to connect FileMaker to modern applications and services covers how to plan that kind of migration without breaking what already works.

Where does this actually get used in a real business?

A few concrete, real-world patterns:

• E-commerce order processing. A webshop (WooCommerce, Shopify, custom) sends new orders to FileMaker via API the moment they're placed, triggering a script that checks stock, reserves inventory, and creates a picking list — instead of someone exporting a CSV once a day.
• Warehouse scanning apps. A barcode scanner app on a phone calls a FileMaker script every time a pallet is scanned, updating stock levels in real time rather than at end-of-shift.
• Customer self-service forms. A form on your website (built with something like FmBetterForms, or a plain web app) submits data that triggers a FileMaker script to validate, create a record, and send a confirmation — without exposing your FileMaker file directly to the public internet.
• AI-assisted workflows. Increasingly, teams connect tools like Klai — an AI layer that can read and act on FileMaker data through natural-language requests — to trigger scripts based on a conversational request ("create a follow-up task for every overdue invoice"). The script itself still does the real work inside FileMaker; the AI tool is just a new, more flexible trigger.
• Cross-system sync. An ERP or accounting package (Exact Online, Twinfield) calls a script to push a new invoice number back into FileMaker the moment it's created, avoiding the double-entry problem where someone re-types the same invoice into two systems.

What breaks if you don't plan this properly?

A few gotchas we've seen trip up real implementations:

• Scripts written for humans, run headless. A script with a "Show Custom Dialog" step will simply hang forever when triggered by an API call, because there's no user to click OK. Every script exposed to the API needs a headless-safe version — no dialogs, no reliance on the active window, no Get(ActiveFieldName) type calls that assume a live user session.
• No idempotency. If the calling system retries a failed request (which webhooks often do automatically), and your script isn't built to recognize "I already processed this order," you get duplicate invoices, duplicate emails, duplicate stock deductions. Always check for an existing record before creating a new one.
• Session and token expiry surprises. Data API sessions expire; if your integration code doesn't handle a 401 and re-authenticate, an integration that worked fine in testing silently stops working in production after a few minutes of inactivity.
• Underestimated concurrency. If ten orders arrive in the same second, does your script handle ten simultaneous script sessions cleanly, or does it assume it's always the only thing running? Server-side scripts queue by default, which is often fine, but it does mean high-volume triggers need capacity planning, not just a working script.
• Security as an afterthought. Any endpoint exposed to the internet needs its own restricted account, HTTPS, and ideally an API gateway or reverse proxy in front of it — never expose FileMaker Server's Data API directly with a shared admin login.

How do you know if this is the right approach for your situation?

Triggering FileMaker scripts via API makes sense when:

• ✅ The business logic already exists and works well inside FileMaker — you just need an external trigger for it.
• ✅ You want real-time or near-real-time processing instead of batch/manual imports.
• ✅ Multiple external systems need to set off the same internal process (an order from the webshop and an order from a sales rep should trigger the identical script).

It's the wrong tool when:

• ❌ You need FileMaker to constantly poll another system for changes (a scheduled server script with a direct API call out is usually simpler than trying to force the other system to push).
• ❌ The volume is extremely high (thousands of triggers per minute) — at that scale, a message queue or middleware layer in front of FileMaker is worth the extra complexity.
• ❌ The script in question was never designed with error handling — retrofitting a fragile script for API use often reveals it needed a rewrite anyway.

FAQ

Can I trigger a FileMaker script from a website form without exposing my whole database? Yes — this is one of the most common and safest use cases. The form submits to a small script-only API account with access limited to exactly the layout and script it needs, nothing else.

Do I need OttoFMS, or is the built-in Data API enough? For most single-integration needs, the built-in Data API is enough. OttoFMS earns its cost when you have many frequent triggers, need webhook receivers, or want easier scheduling and monitoring across several integrations.

What data format does the script receive? The API passes a single script parameter, typically as a JSON string, which your script parses with JSONGetElement or similar. Design the script to validate that JSON before acting on it — never assume the payload is well-formed.

Can this work with AI tools, not just other software systems? Yes — tools like Klai can call FileMaker scripts as part of an AI-driven workflow, effectively letting a natural-language request become the trigger, with the actual script still doing the deterministic, auditable work inside FileMaker.

A quick checklist before you go live

• Dedicated API account with minimum required privileges
• Script rewritten to be headless-safe (no dialogs, no assumed active window)
• Idempotency check built into the script
• Logging table capturing every triggered run
• Token refresh / re-authentication handled in the calling code
• HTTPS and, ideally, a reverse proxy or API gateway in front of the endpoint
• Failure paths tested, not just the happy path
• Concurrency/volume expectations discussed with whoever built the script

If your FileMaker system already does the right thing once someone opens it and clicks a button, the real opportunity is making that logic reachable from everywhere else your business runs — the webshop, the warehouse app, the accounting package, or an AI assistant your team already uses. Loggix builds these API connections as part of custom FileMaker development, and can also help design the surrounding architecture — from a dedicated API layer to a broader system integration — so the scripts you already trust keep doing the work, just triggered from wherever the business actually happens.