How to connect FileMaker to Shopify

You're running your business logic — orders, inventory, production, invoicing — in FileMaker. Your webshop runs on Shopify. Right now, someone on your team is opening the Shopify admin every morning, checking new orders, and typing them into FileMaker by hand: customer name, address, items, quantities, payment status. Or worse — stock levels drift apart because nobody updates FileMaker when Shopify sells the last unit of something, and a customer orders a product that's already out of stock.

This article walks through exactly how to connect FileMaker to Shopify in a way that actually holds up in daily use — not just a proof-of-concept that breaks the first time Shopify changes a field.

Why does this integration matter more than it seems?

On paper, "sync orders from Shopify into FileMaker" sounds like a small job. In practice, it touches almost everything:

• Orders need to flow into FileMaker with correct line items, taxes, discounts, and shipping costs.
• Inventory needs to flow the other way, so Shopify never sells something FileMaker knows is out of stock.
• Customers need to be matched or created without duplicating every returning buyer.
• Fulfillment and tracking numbers often need to go back to Shopify so the customer gets a shipping notification.
• Refunds and cancellations need to be reflected in both systems, or your finance numbers stop matching reality.

Miss one of these and you end up with a "partial integration" that still requires manual double-checking — which defeats the point.

What are the actual ways to connect FileMaker and Shopify?

There are three realistic approaches, and the right one depends on volume and complexity.

1. Shopify's REST Admin API (or GraphQL Admin API) called directly from FileMaker

FileMaker's native Insert from URL script step, combined with the JSONSetElement/JSONGetElement functions, can call Shopify's Admin API directly. This works well for:

• Pulling new orders on a schedule (e.g. every 5 minutes via FileMaker Server's scheduled scripts).
• Pushing inventory levels back to Shopify after a stock change in FileMaker.
• Creating or updating customer records.

This is the leanest option — no middleware, no extra hosting cost — but it puts the burden of error handling, pagination, and rate-limit management entirely on your FileMaker scripts.

What does the order sync actually look like, step by step?

A solid FileMaker–Shopify order sync generally runs like this:

1. Authenticate. Create a custom Shopify app (or use Shopify's Partner dashboard) to get an API access token scoped to exactly the permissions you need — read_orders, write_inventory, read_customers, etc. Never use broader scopes than necessary.
2. Poll or listen. Either poll GET /admin/api/2024-01/orders.json on a schedule, or register a webhook (orders/create, orders/paid, orders/cancelled) that pushes data to a FileMaker Data API endpoint the moment something happens. Webhooks are more efficient and near-real-time; polling is simpler to build and debug.
3. Parse the JSON. Shopify returns nested JSON — line items, shipping address, tax lines, discount codes — all inside one order object. Map each of these into your FileMaker order and line-item tables.
4. Match or create the customer. Use Shopify's customer.id as the match key stored in FileMaker, not the email address alone — customers change emails, but the Shopify ID stays stable.
5. Write the order into FileMaker, including a field that stores the original Shopify order ID and financial/fulfillment status, so future updates (refunds, edits) can find the right record again.
6. Acknowledge and log. Log every sync attempt with a timestamp and status, so when something fails at 2 a.m. you can see exactly which order didn't come through — instead of discovering it three days later from an angry customer email.
7. Push fulfillment back. Once a warehouse team marks an order as shipped in FileMaker, call POST /admin/api/2024-01/orders/{id}/fulfillments.json so Shopify sends the customer their tracking email automatically.

How do you keep inventory in sync without overselling?

This is where most DIY integrations quietly fail. Two patterns work reliably:

• FileMaker as the source of truth for stock. Every time a stock quantity changes in FileMaker (production, receiving, manual correction), a script pushes the new quantity to Shopify's Inventory API (inventory_levels/set). This is the right pattern if manufacturing, purchasing, or warehouse counts happen in FileMaker.
• Shopify as the source of truth for sold quantities, FileMaker reconciles. Every Shopify order webhook decrements stock in FileMaker immediately, and a nightly job reconciles any drift.

Whichever direction you choose, pick one system as the authority for stock at any given moment. Trying to let both systems "own" inventory simultaneously is the single most common cause of overselling.

When do you need middleware instead of a direct connection?

Calling the Shopify API directly from FileMaker Server scripts works well up to a moderate order volume — roughly a few hundred orders a day. Beyond that, or if you also need to sync with an ERP, accounting package (Exact, Twinfield, Visma), or a shipping carrier at the same time, it's often worth introducing a small middleware layer — a lightweight web app or serverless function that:

• Receives Shopify webhooks instantly (no polling delay).
• Queues and retries failed calls instead of losing them.
• Translates data once, then distributes it to FileMaker and other systems, so FileMaker doesn't become the traffic cop for every connected app.

This is the same architectural question we cover in more depth in our guide on connecting FileMaker to modern applications and services — Shopify is one specific, very common case of that broader pattern.

What usually goes wrong — and how do you avoid it?

• Rate limits. Shopify's Admin API allows a limited number of calls per second (bucket-based). Bulk operations (e.g. re-syncing thousands of historic orders) need throttling logic, or you'll get 429 Too Many Requests responses and silent gaps.
• Currency and tax mismatches. Shopify calculates tax based on shop settings and customer location; if your FileMaker invoicing logic recalculates tax independently, the two totals can disagree by cents — enough to confuse a customer or an accountant.
• Duplicate customers. Matching only on email address creates duplicates when a customer checks out as a guest with a slightly different email each time. Match on Shopify customer ID first, email as fallback.
• Webhook payload changes. Shopify occasionally deprecates API versions. Pin your integration to a specific API version (e.g. 2024-01) and review Shopify's changelog before upgrading, rather than letting calls silently fail after a forced migration.
• Partial failures. An order with 12 line items where line item #9 fails to parse shouldn't quietly skip the whole order. Build error handling that flags and logs the specific failure, not just "success/fail" at the order level.

What about AI-assisted matching and support?

Once orders, customers, and products are flowing between Shopify and FileMaker, some businesses layer AI on top — for example, using a natural-language layer inside FileMaker (this is where tools like Klai come in) to let a support team ask "which Shopify orders from last week are still unfulfilled and above €200?" without writing a find request or a script by hand. This isn't required to get the integration working, but it's a natural next step once the data is reliably synced.

How do you keep the FileMaker side of this maintainable?

If your FileMaker order and customer screens are built with a modern, flexible layout foundation — tools like FMBetterForms make it easier to build responsive, clean interfaces for order review, fulfillment status, and customer lookups — it's much easier to extend the UI later as your Shopify integration grows (adding return handling, loyalty points, or subscription orders) without rebuilding layouts from scratch.

Checklist: is your FileMaker–Shopify connection production-ready?

• API token scoped to only the permissions actually needed
• Webhooks (not just polling) for order creation, payment, and cancellation
• Shopify order ID and customer ID stored in FileMaker for reliable matching
• One system clearly defined as the authority for stock levels
• Fulfillment/tracking data pushed back to Shopify automatically
• Logging of every sync attempt, with visibility into failures
• API version pinned, with a plan to review Shopify's changelog periodically
• Rate-limit handling for bulk or historic syncs

FAQ

Does this require the Data API or can it run entirely in FileMaker Server scripts? Both work. Outbound calls to Shopify (pulling orders, pushing inventory) can run as FileMaker Server scheduled scripts using Insert from URL. Inbound webhooks from Shopify need something to receive an HTTP POST — either the FileMaker Data API behind a small receiving endpoint, or a lightweight middleware service that then writes into FileMaker.

Can this work with Shopify Plus or only regular Shopify? The core Admin API and webhook approach works on any Shopify plan. Shopify Plus adds features like multi-currency and B2B storefronts, which add extra fields to map but don't change the fundamental integration pattern.

How long does a solid integration like this typically take to build? A focused order-and-inventory sync, done properly with error handling and logging, is usually a few weeks of development — not a weekend project, if it needs to survive real order volume without daily manual checking.

If your team is still bridging FileMaker and Shopify by hand — checking orders every morning, updating stock manually, or double-checking totals in a spreadsheet — that's a sign the integration is overdue rather than optional. Loggix builds custom FileMaker solutions and API integrations that connect systems like Shopify, ERPs, and accounting platforms reliably, and can also help map out the right architecture — direct API calls versus middleware — before a single line of code is written.