How to design reliable integrations between business systems

Your warehouse team updates stock levels in one system. Your sales team looks up inventory in another. By the time a customer asks whether something is in stock, the two systems are already six hours out of sync — and someone has to make a call based on a number they don't quite trust. That's not a technology problem. That's a design problem. This article walks you through how to design integrations between business systems that are reliable, maintainable, and built to survive real-world conditions.

Why do integrations fail in the first place?

Most integration failures share a common origin: they were not designed — they were patched together. A spreadsheet export here, a copy-paste routine there, an intern who manually re-enters orders from one system into another every morning. Over time, these workarounds calcify into "the process," and the business becomes dependent on them without realising how brittle they are.

The three most common failure modes are:

1. Manual data entry — An order arrives in your CRM, and a colleague types it by hand into your ERP. Every single order, every single day. One typo in a customer number and the invoice goes to the wrong address.
2. Broken synchronisations — A scheduled sync job runs at night, but nobody monitors it. It silently fails for three days because an API endpoint changed. By the time someone notices, the product catalogue in your webshop is three days behind.
3. Delayed or inconsistent data — Finance pulls a revenue report from System A. Operations pulls shipment data from System B. The two numbers don't agree because they were generated at different moments with different filters. Decisions get made on data that contradicts itself.

None of these are exotic edge cases. They are the norm in businesses that have grown faster than their software architecture.

What should a reliable integration actually do?

Before choosing a technology, get clear on what the integration must achieve. A reliable integration:

• Moves data without human intervention on the routine path
• Validates data before writing it anywhere (so a blank field in the source doesn't corrupt the destination)
• Fails loudly, not silently — when something goes wrong, someone is notified immediately
• Is idempotent where possible — running the same sync twice produces the same result, not duplicate records
• Keeps an audit trail — you can always answer "when did this record change, and what triggered it?"
• Is documented well enough that a developer who didn't build it can maintain it

These are not nice-to-haves. Each one corresponds to a class of production failure you will eventually hit if it is missing.

Which integration pattern fits your situation?

Choosing the right pattern matters more than choosing the right tool. Here are the five main approaches, with honest guidance on when each one belongs.

REST APIs — the workhorse for most integrations

A REST API lets one system request data from, or send data to, another system over HTTP. It is the most common integration pattern today because virtually every modern business application exposes one.

When to use it: When you need to trigger an action in another system (create an invoice, update a customer record, retrieve a product list) on demand or on a schedule. REST is a good fit for integrations where the initiating side controls the timing.

Real example: Your FileMaker order management system calls the Exact Online REST API the moment an order is marked "confirmed" — creating a sales invoice automatically, without anyone touching Exact Online.

Watch out for: Rate limits (most APIs cap how many requests you can make per minute), authentication token expiry, and API versioning — when the vendor updates their API, your integration can break without warning if you have not built in version-checking.

Webhooks — when the other system should tell you first

A webhook flips the REST model around. Instead of your system polling another system for changes, the other system pushes a notification to your system the moment something happens.

When to use it: When you need near-real-time reaction to events in an external system. A payment platform confirming a transaction. A logistics provider updating a shipment status. A form submission triggering a record creation.

Real example: Mollie sends a webhook to your FileMaker server the instant a payment is confirmed. The order status updates within seconds — no polling, no lag, no night-time batch job.

Watch out for: Webhooks require your receiving endpoint to be reliably reachable (correct SSL certificate, stable URL, no firewall blocking). You also need to handle duplicate delivery — most webhook providers send the same event more than once if they don't receive a timely acknowledgement. Your endpoint must be idempotent.

Middleware / iPaaS — when you're connecting more than two systems

Middleware platforms (sometimes called iPaaS — Integration Platform as a Service) sit in the middle of your landscape and orchestrate data flows between multiple systems. Examples include Make (formerly Integromat), n8n, Zapier, and enterprise-grade options like MuleSoft or Azure Integration Services.

When to use it: When you have three or more systems that need to exchange data, when you want to build integrations without writing custom code for every connector, or when you need a central place to monitor all your data flows.

Real example: A new contact in HubSpot CRM automatically creates a customer record in FileMaker, triggers a welcome email via Mailchimp, and adds a task in your project management tool — all orchestrated by a single Make scenario, with one dashboard to monitor them all.

Watch out for: iPaaS platforms introduce a dependency on a third-party service. If Make goes down, your integrations go down. Also, complex business logic (conditional routing, data transformation, error handling) can become hard to maintain inside a visual workflow builder — at some point, custom code is cleaner.

iPaaS vs. custom API connector — the honest trade-off: iPaaS is faster to set up and easier to change without a developer. A custom connector is more robust, more performant, and puts you in full control of error handling and retry logic. For simple, low-volume flows, iPaaS wins on speed. For business-critical, high-volume, or complex transformations, build it properly.

FileMaker Data API — integrating FileMaker with the rest of your stack

The FileMaker Data API is a REST API built into the FileMaker platform that lets external systems read from and write to FileMaker databases over HTTP. It is the right tool when FileMaker is one node in a broader integration landscape.

When to use it: When an external application (a webshop, a customer portal, a reporting tool, a third-party service) needs to interact with data stored in FileMaker — without requiring FileMaker client licences for every user.

Real example: A custom web portal lets your customers view their order history and download invoices. The portal calls the FileMaker Data API to fetch records in real time — the customer sees live data from FileMaker without ever opening FileMaker itself.

Watch out for: The FileMaker Data API uses session tokens that expire after inactivity. Your integration must handle token renewal gracefully, or you will get sporadic authentication errors that are hard to reproduce. Also, avoid exposing the FileMaker Data API directly to the public internet without an intermediary layer that handles authentication, rate limiting, and input sanitisation.

Direct database integration — powerful, but handle with care

A direct database connection bypasses application APIs entirely and reads from or writes to the underlying database (SQL Server, MySQL, PostgreSQL, etc.) directly.

When to use it: When no API exists, when performance is critical (bulk data transfers, large-scale reporting), or when you are integrating systems you fully own and control.

Real example: A nightly ETL (Extract, Transform, Load) job pulls raw transactional data from your ERP's SQL database into a separate data warehouse, where it feeds a Power BI dashboard — without loading the ERP's own reporting module.

Watch out for: Direct database access is tightly coupled to the database schema. When the ERP vendor releases an update that renames a table or column, your integration breaks — and the vendor owes you nothing because you bypassed their official interface. Use direct database access only for systems you control, and always document the schema dependency explicitly.

How do you actually build a reliable integration? A step-by-step approach

Here is the sequence that experienced integration architects follow — not the shortcut that leads to 2 a.m. support calls.

1. Map the data flow on paper first. Draw which system owns each piece of data, which direction it flows, and what triggers the movement. Do this before opening a code editor or configuring a workflow tool.
2. Define the source of truth. For every data field, decide: which system is authoritative? Customer address lives in the CRM. Inventory quantity lives in the WMS. Never let two systems both think they own the same field — that is how you get conflicts.
3. Agree on the data contract. Document the exact field names, data types, formats, and allowed values on both sides. A date field in one system might be DD-MM-YYYY; in another it might be a Unix timestamp. Discover this now, not in production.
4. Build error handling before happy-path logic. What happens when the destination system is unreachable? When a required field is null? When the API returns a 429 (rate limit)? Define retry logic, dead-letter queues, and alerting before you write the main sync logic.
5. Log everything with context. Every data exchange should produce a log entry: timestamp, source record ID, destination record ID, status, and any error message. "The sync failed" is useless. "Order #10482 failed to create in Exact Online at 14:37 because customer ID was null" is actionable.
6. Test with production-realistic data. Edge cases that never appear in your clean test dataset appear constantly in real data: special characters in names, unusually long descriptions, duplicate records, null values where none were expected.
7. Monitor continuously, not reactively. Set up alerts for failure rates, unusual data volumes (a sync that normally moves 200 records suddenly moving 0 is probably broken, not quiet), and latency spikes. Do not wait for a user to report a problem.
8. Document the integration for the next developer. Write down what the integration does, why it exists, which credentials it uses and where they are stored, and what to do when it breaks. This is not optional — it is the difference between a maintainable system and a black box.

Integration design checklist

Before you go live with any integration, run through this list:

• Source of truth is defined for every synced field
• Data contract is documented (field names, types, formats, validation rules)
• Error handling covers: unreachable endpoint, invalid data, rate limits, auth expiry
• Retry logic is in place with backoff (not an infinite retry loop)
• Logging captures enough context to diagnose any failure
• Integration is idempotent (safe to run twice without duplicating data)
• Monitoring and alerting is active before go-live
• Credentials are stored securely (not hardcoded in scripts)
• The integration is documented for the next maintainer
• A rollback or manual override procedure exists

Frequently asked questions

How often should I sync data between systems? It depends on how stale data causes harm. Inventory levels that feed a live webshop need near-real-time sync (webhooks or sub-minute polling). A financial summary that feeds a weekly management report is fine with a nightly batch. Over-engineering real-time sync for data that only changes once a day wastes infrastructure and creates unnecessary failure points.

Should I build integrations myself or use an iPaaS platform? For straightforward, low-volume connections between well-supported applications, an iPaaS like Make or n8n gets you there faster and is easier for non-developers to maintain. For high-volume flows, complex business logic, or mission-critical processes where a third-party outage is unacceptable, a custom integration gives you more control and resilience. Many mature businesses use both: iPaaS for simpler flows, custom connectors for the critical ones.

What's the biggest mistake companies make with integrations? Building the happy path and ignoring error handling. The integration works perfectly in testing — data is clean, both systems are up, the API behaves as documented. In production, none of those conditions hold consistently. The integrations that survive for years are the ones built with failure as the default assumption, not the exception.

How do I handle data that already exists in both systems before the integration goes live? This is the initial data migration problem, and it deserves its own project phase. Before activating live sync, you need to reconcile existing records: identify duplicates, establish which system's version is authoritative, and clean up inconsistencies. Skipping this step means your new integration inherits all the old mess and amplifies it.

What should I do when an API endpoint changes and breaks my integration? First, make sure you are subscribed to the vendor's changelog or developer newsletter — most breaking changes are announced weeks in advance. Second, build your integration against a versioned endpoint (e.g. /api/v2/orders) rather than an unversioned one. Third, write integration tests that run against a staging environment so you catch breakage before it hits production.

Is a direct database connection ever acceptable? Yes — when you own both systems, you control schema changes, performance requirements are high, and no API exists. It is not acceptable when you are connecting to a vendor-managed system, because schema changes made during a vendor update can silently corrupt your integration.

---

Designing integrations that hold up in production is rarely about picking the fanciest technology — it is about discipline: clear data ownership, explicit contracts, honest error handling, and continuous monitoring. If your business is running on a tangle of manual exports, overnight batch jobs, and integrations nobody fully understands anymore, that is exactly the kind of problem Loggix works on every day. Whether the right answer is a custom API connector, a FileMaker-based integration layer, a middleware setup, or a full redesign of how your systems talk to each other, Loggix can map out the architecture with you and build it to last.