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 native step for calling web services. Handles GET and POST, basic authentication, and standard JSON payloads. Requires no plugin. Works for prototype calls, occasional operations, and simple integrations where reliability is not critical. Has quirks around certain TLS configurations and error handling that surface when the integration matters.

MBS CURL functions (plugin). The reliable path for production integrations. Better error handling, better TLS behavior, richer HTTP feature support, and consistent behavior across FileMaker Server versions and macOS updates. Requires an MBS plugin license, which is worth mentioning in the integration budget conversation. For anything that runs in production and matters when it doesn't work, MBS is the preferred choice.

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. A REST endpoint FileMaker Server exposes for reading, writing, and running scripts against your file. Standard authentication, standard JSON, works with any tool that speaks REST — which is nearly all modern services. Zapier connects through it. Custom middleware talks to it. Web apps ride on top of it. This is the mechanism most integrations use as their inbound layer.

OData. A SQL-shaped query interface Claris added in more recent versions. Useful specifically when the consuming tool speaks OData natively — Power BI, some ERPs, Excel PowerQuery. Not a replacement for the Data API. A different shape for a specific class of tools.

Webhooks (via a small middleware service). FileMaker cannot directly receive webhooks from other services, because FileMaker Server does not expose an arbitrary HTTP endpoint. What handles this is a small middleware service — FastAPI, Node, or similar — that receives the webhook and translates it to a Data API call. This is the standard pattern for reliable event-driven integrations: Stripe confirming a payment, Shopify announcing an order, SendGrid confirming an email delivery. The middleware is a small piece of infrastructure — usually a few hundred lines of code — that 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 as sync targets rather than replacements.
  • Analytics and BI: Power BI, Tableau, Google Sheets. Often via OData or a scheduled export to a shared spreadsheet.
  • No-code glue: 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:

Webhooks over polling. Don't have FileMaker check the other system every five minutes for updates. Have the other system push events as they happen. Push is faster, uses fewer resources, and reveals its own failures more clearly than a silent polling loop that stopped working three weeks ago.

Idempotency. Any incoming event should be safe to process twice. Webhooks retry. Users click twice. Networks glitch. If your handler creates a new record every time a webhook arrives, duplicates accumulate — small ones for months, then a big cleanup nobody wants to do. Every event carries an ID from the source; the handler recognizes duplicates by that ID and does not double-post.

Retry with backoff. Transient failures are common. The upstream service is momentarily unavailable, a rate limit was hit, TLS handshake failed. The integration should retry, waiting longer each time, and only escalate to a human 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 grep through Console logs from three weeks ago" the answer is effectively no. A small integration log — the last thousand events, timestamps, statuses, payloads — is a small effort that pays for itself the first time it's needed.

Reliability lives in the boring details: webhooks, idempotency, retries, and a log you can actually read.

What it costs.

Simple integrations (single direction, low volume, well-documented API — e.g. sending order confirmations via SendGrid, creating Zapier webhooks): $3,000 to $8,000.

Standard integrations (bidirectional, moderate complexity, webhook handling — e.g. Stripe payments, Shopify order sync, QuickBooks invoicing): $8,000 to $20,000.

Complex integrations (multiple systems, custom business logic, high volume, unusual data shapes — e.g. multi-warehouse ERP sync, custom API with a legacy system, high-throughput event processing): $20,000 to $50,000 or more.

Ongoing costs are usually small once built — third-party service fees (Stripe, Twilio, ShipStation charge per transaction), hosting for any middleware service (typically $10-50/month), and occasional maintenance as external APIs update.

What to do next.

The free triage call is where the specific integration gets sorted honestly. 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 and you'll have a rough scope, a real cost range, and a sense of which mechanisms fit the shape.