The short version.

FileMaker connects to other systems in two directions. Outbound, a FileMaker script calls another service's API — sending an invoice to QuickBooks, pushing a shipment to ShipStation, creating a payment link at Stripe. Inbound, another service reads from or writes to FileMaker — Zapier picking up a new record, a webhook confirming a Stripe payment, Power BI pulling data for a dashboard.

Both directions have well-established mechanisms. The right choice depends on the direction, the volume, and how critical it is that the integration keeps working when nobody is watching.

The direction matters more than the technology. Who is calling whom decides which tool fits.

Outbound — FileMaker calling other systems.

Two mechanisms.

Insert from URL (built-in). FileMaker's built-in step for calling other services over the web. No plug-in needed. Fine for occasional calls and simple connections where a hiccup isn't costly. It has quirks with some secure connections and with error handling that show up when the connection matters.

MBS CURL functions (plugin). The dependable choice for connections the business relies on. It handles errors and secure connections better, and behaves the same across FileMaker Server versions and macOS updates. It needs an MBS plug-in license, so it belongs in the budget talk. For anything that matters when it fails, MBS is my pick.

The heuristic: if the integration failing on a Tuesday morning is inconvenient, Insert from URL is fine. If the failure would cost the business money or trust, use MBS.

Inbound — other systems calling FileMaker.

Three mechanisms.

Data API. The main path. FileMaker Server's built-in door that other software uses to read and write your records and run scripts. Nearly every modern service knows how to use it. Zapier connects through it, and so do web apps that run next to FileMaker. Most connections into FileMaker use it.

OData. A second door Claris added in newer versions, shaped for reporting tools: Power BI, some business systems, Excel. It doesn't replace the Data API; it suits those tools.

Webhooks (instant notices from other services). FileMaker Server can't take these in by itself. A small go-between service receives each notice and hands it to FileMaker through the Data API. It's the standard way to hear about something the moment it happens: Stripe confirming a payment, Shopify announcing an order, SendGrid confirming an email went through. It's usually a few hundred lines of code, and it pays for itself in reliability.

Common integrations by category.

  • Payments: Stripe (worked through in detail on the Stripe integration page), Square, PayPal.
  • E-commerce: Shopify, WooCommerce, BigCommerce. Order sync, inventory push, customer creation.
  • Accounting: QuickBooks Online, Xero, Sage. Invoice sync, customer sync, payment reconciliation.
  • Shipping and logistics: ShipStation, EasyPost, USPS/UPS/FedEx APIs. Rate quotes, label generation, tracking updates.
  • Communication: Twilio for SMS, SendGrid or Postmark for transactional email, Slack for internal notifications.
  • CRM (outside FileMaker): HubSpot, Salesforce, Pipedrive — usually kept in step with FileMaker rather than replacing it.
  • Reporting and analytics: Power BI, Tableau, Google Sheets. Often via OData or a scheduled export to a shared spreadsheet.
  • Connector services: Zapier and Make.com. Sometimes the fastest path for a simple integration that connects two systems that already exist.
  • Industry-specific: veterinary (ezyVet), medical practice systems, legal case management, real estate MLS. These usually have documented APIs and well-known integration patterns.

What makes an integration reliable.

Working most of the time is not enough for an integration that touches money, orders, or customer records. Four specific practices separate a working integration from one that occasionally loses data:

Get notified instead of checking. Don't have FileMaker check the other system every five minutes. Have the other system send word the moment something happens (a webhook). That's faster, does less work, and a failure shows up instead of hiding in a check that quietly stopped three weeks ago.

Idempotency: safe to receive twice. Any notice should be safe to handle twice. Webhooks retry. Users click twice. Networks glitch. If FileMaker creates a new record every time a notice arrives, duplicates pile up — small ones for months, then a big cleanup nobody wants to do. Every notice carries an ID from the sender; FileMaker spots one it has already seen and doesn't post it twice.

Retry, waiting longer each time. Brief failures are common: the other service is down for a moment, it's limiting how fast you can send, or a secure connection didn't go through. The connection should try again, waiting a little longer each time, and only call a person after several failures. Most of these errors resolve themselves in seconds.

Logging you can actually look at. Every integration eventually has a "did that fire?" moment. If the answer is "let me dig through three-week-old server logs," the answer is effectively no. A small integration log — the last thousand events, when each happened, whether it worked, and what was sent — is a small effort that pays for itself the first time it's needed.

Reliability lives in the boring details: getting notified instead of checking, handling repeats, retrying, and a log you can actually read.

What sets the size of the job.

Simple integrations (single direction, low volume, well-documented API — e.g. sending order confirmations via SendGrid, creating Zapier webhooks): the small end.

Standard integrations (two-way, a few moving parts, instant notices — e.g. Stripe payments, Shopify order sync, QuickBooks invoicing): the middle.

Complex integrations (multiple systems, custom rules, high volume, unusual data — e.g. keeping several warehouses in step, connecting to an old system with no standard door, thousands of events an hour): the large end.

Ongoing costs are usually small once built — third-party service fees (Stripe, Twilio, ShipStation charge per transaction), hosting for any go-between service, and occasional maintenance as external APIs update.

What to do next.

The free triage call is where we scope the specific integration. You describe what you're trying to connect, roughly the volume, whether the failure would cost the business money, and how urgent the timeline is. Thirty minutes gets you a rough scope, and you'll know which mechanism fits. The System Assessment turns that into a quote.