How to combine FileMaker with a web application

Your operations team runs beautifully on FileMaker. Order processing, inventory, production planning — it all just works, and everyone in the office knows how to use it. But now your customers want a self-service portal to check order status, your field technicians want a mobile-friendly form that works over a spotty 4G connection, and your logistics partner wants to query stock levels automatically. Suddenly "just use FileMaker" isn't a good enough answer anymore.

This is one of the most common turning points in a FileMaker system's life. It doesn't mean FileMaker was the wrong choice — it means the audience for your data has grown beyond the people sitting at a desk with FileMaker Pro or Go installed. This article walks through the realistic options for combining FileMaker with a web application, what each one actually involves, and the mistakes that turn a good idea into a maintenance headache.

Why would you connect FileMaker to a web app at all?

Three situations come up again and again:

• External users need access, but not full FileMaker access. A customer portal, a supplier form, or a public order-tracking page shouldn't require installing FileMaker Go or handing out named user licenses to people outside your company.
• You need something FileMaker's native interface can't easily deliver. A public-facing website with SEO-friendly pages, a slick consumer-grade booking flow, or a dashboard embedded in another company's intranet.
• Scale or concurrency demands it. If you expect thousands of anonymous visitors hitting a form at once — think a product configurator or an event registration page — that's a different load profile than 40 employees using FileMaker internally.

Notice what's not on this list: "because FileMaker is old." A well-maintained FileMaker back end is often the fastest, cheapest way to run internal business logic. The web layer is about reaching people FileMaker itself was never meant to reach directly.

What are the real ways to connect FileMaker to a web application?

There are three architectures worth knowing, and picking the wrong one is the single biggest cause of project pain.

1. FileMaker's Data API (REST)

Claris FileMaker Server ships with a built-in Data API that exposes your tables, layouts, and scripts as REST endpoints. A web application — built in anything from plain JavaScript to React, Vue, or a Node/PHP back end — can call this API to read and write records.

Good for: small to medium web apps, internal portals, situations where FileMaker stays the single source of truth and the web app is essentially a thin front end.

Gotcha: the Data API authenticates per session token and has request-based licensing implications on FileMaker Server. A public page hit by thousands of anonymous visitors a day can rack up API calls fast — budget for that before you build, not after the invoice surprises you.

2. A middleware/API layer in front of FileMaker

Instead of the web app talking to FileMaker directly, you insert a small integration layer (a lightweight Node.js, PHP, or dedicated API connector service) between the two. The web app calls the middleware; the middleware calls FileMaker's Data API, applies business rules, caches responses, and handles retries.

Good for: anything customer-facing, anything with real traffic volume, or any situation where you don't want the public internet talking directly to your production FileMaker Server.

This is the pattern we use most often at Loggix for customer portals: FileMaker stays the operational core, a purpose-built API connector translates and secures the traffic, and the web app never needs to know FileMaker exists at all.

3. Two separate systems synced by integration

Sometimes it's simpler to build the web application as its own system — with its own database — and sync relevant records with FileMaker on a schedule or via webhooks, rather than querying FileMaker live for every page load.

Good for: high-traffic public sites, situations where the web app needs to work even if FileMaker Server is briefly down for maintenance, or where the web app has its own complex logic unrelated to FileMaker.

Trade-off: you now have two sources of truth that must stay in sync, which means conflict handling, sync frequency decisions, and monitoring for failed syncs become part of the ongoing maintenance, not a one-time setup task.

What does a real implementation look like?

A concrete example: a wholesale distributor had all order and inventory data in FileMaker, used internally by 15 staff. Their biggest customers kept calling to ask "where's my order," tying up two people almost full time. The fix wasn't to give customers FileMaker logins — it was a small web portal where a customer logs in, sees their own order history and live status, pulled through a middleware API that queries FileMaker's Data API and returns only that customer's records. FileMaker never changed its role as the operational system; the web app just gave the right slice of that data to the right audience.

Another common case: a manufacturer needed a public product configurator on their marketing website. Traffic was unpredictable and sometimes spiky after a trade show. Rather than hammering FileMaker Server directly, configurations were submitted to a queue, validated, and only written into FileMaker in batches — protecting the production system from a traffic spike nobody planned for.

How do you decide which approach fits your situation?

Walk through these questions before writing a line of code:

1. Who is the audience, and how many of them? Ten known partner companies is a very different load than an open public form.
2. Does the web app need live, real-time data, or is near-real-time (synced every few minutes) good enough? Live queries are simpler to build but harder to scale; sync is more resilient but adds complexity.
3. What happens if FileMaker Server is down for scheduled maintenance? If the answer is "the web app must still work," you need a synced or cached architecture, not a live query.
4. Who owns security for this data once it's on the web? Exposing FileMaker data externally means rethinking authentication, rate limiting, and what fields are actually safe to expose — this is not the same trust model as internal FileMaker accounts.
5. What's the realistic request volume, and what does that mean for FileMaker Server licensing? Get a number, even a rough one, before committing to a direct Data API approach.

What are the common mistakes to avoid?

• Exposing raw FileMaker tables directly to the web app. Always go through scripts or a controlled API layer so business logic and validation aren't bypassed by a browser request.
• Ignoring concurrency limits. FileMaker Server has practical limits on simultaneous connections; a web app built without awareness of this can quietly degrade performance for internal users too.
• Treating the web app as a full FileMaker replacement. Rebuilding your entire operational logic in the web app duplicates work you already solved in FileMaker — the point is to extend reach, not rebuild the core.
• Skipping the security review. Anything reachable from the public internet needs its own authentication, input validation, and logging separate from FileMaker's internal user permissions.
• No monitoring on the sync or API layer. If middleware silently fails at 2am, you want an alert, not an angry customer email the next morning.

Quick checklist before you start

• Defined exactly who the external users are and roughly how many
• Decided: live Data API call, middleware layer, or synced separate system
• Checked FileMaker Server licensing against expected request volume
• Decided what happens if FileMaker Server is temporarily unavailable
• Listed exactly which fields/records are safe to expose externally
• Planned authentication and rate limiting for the web-facing layer
• Set up monitoring/alerting for the integration itself

FAQ

Can I just use FileMaker WebDirect instead of building a separate web app? WebDirect renders your existing FileMaker layouts in a browser, which is fast to set up but still requires FileMaker Server licensing per user and doesn't give you a custom-designed, SEO-friendly, or fully branded experience. It's a good stopgap for internal or semi-trusted users, not usually the right fit for a public customer-facing site.

Does the web app need to be built in a specific language to talk to FileMaker? No — because the Data API is REST-based, any language that can make HTTP calls (JavaScript, PHP, Python, Node.js, .NET) can integrate with FileMaker.

Is it safe to expose FileMaker data to the public internet? Yes, if it goes through a proper API layer with authentication, input validation, and scoped permissions — never by opening FileMaker Server directly to public traffic.

How long does a typical FileMaker-to-web-app integration take? A simple middleware-based portal for a handful of read-only views can often be built in a few weeks; a synced two-system architecture with its own database, webhooks, and conflict handling is a larger project, typically measured in months depending on complexity.

If this step is part of a bigger modernization effort, it's worth reading the full approach in how to modernize a FileMaker system step by step, which covers where a web layer fits alongside other modernization decisions like API strategy and phased rollouts.

Combining FileMaker with a web application is rarely an all-or-nothing rebuild — it's usually a matter of choosing the right connection pattern for your actual audience and traffic, then building a clean, secure layer between the two. Loggix regularly helps teams work through exactly this kind of decision: whether that means building a tailored web application on top of an existing FileMaker system, developing an API connector to bridge the two safely, or simply mapping out the right architecture in a short consultancy session before any code gets written.