How to decide whether a system needs an API

Your team re-enters the same order data into three different systems every day. Someone copies a customer record from your webshop into your ERP by hand, and then a colleague keys the same invoice into your accounting package. Errors creep in, reconciliation eats hours, and no one can tell you in real time what stock is actually available. This article walks you through a structured way to decide whether connecting a system via an API is the right solution — and when it isn't.

What is an API, and why does it matter for business systems?

An API (Application Programming Interface) is a defined channel through which two software systems can exchange data automatically, without human intervention. Think of it as a digital handshake: System A says "here is an order," and System B immediately receives, processes, and confirms it — no copy-paste, no spreadsheet in between.

For business owners and IT managers, the practical meaning is this: an API eliminates the human step in data transfer. Instead of an employee copying an order from your webshop into your ERP at the end of the day, the connection fires the moment the customer clicks "confirm." The ERP updates inventory, triggers a pick list in the warehouse, and posts a draft invoice to Exact Online — all within seconds.

APIs are not new, but their availability has exploded. Nearly every modern SaaS platform — Exact Online, Shopify, WooCommerce, Salesforce, Mollie, PostNL — publishes a documented REST API. That means integrating them is now a question of engineering effort and architectural decisions, not of whether it's technically possible.

How do you know your business actually has an API problem?

Before you commission an integration, it's worth being honest about what you're actually observing. The symptoms below are strong signals that manual data flow is the root cause:

• Double entry is routine. An order gets entered into FileMaker, and then re-typed by hand into Exact Online — every single order, every single day.
• Errors cluster at handoff points. Mistakes don't appear randomly; they consistently happen when data moves from one system to another (wrong quantity, wrong customer number, transposed digits).
• Reporting requires a manual assembly step. Before a manager can see a consolidated sales figure, someone has to pull exports from two or three systems and combine them in Excel.
• Your team is growing but so is the admin load. More orders mean proportionally more data-entry hours — a sign the process doesn't scale.
• Decisions are delayed by data lag. Stock levels in your ERP are only accurate after someone has processed the webshop orders, which happens once a day — or less.

If two or more of these describe your situation, you have a genuine integration problem. An API connection is likely the right category of solution. But "likely" isn't "certainly" — read on before you start scoping.

What are the decision criteria for whether a system needs an API?

Use this framework to evaluate each system in your landscape:

1. Does the system have a published API?

This is the starting gate, not the finish line. Most modern platforms do. Legacy systems — an older FileMaker database, an on-premise ERP from 2008, a bespoke Access database — often don't. If a system has no API, you have three paths: use an intermediate layer (a middleware tool or a custom connector), export/import files on a schedule (less elegant, but sometimes good enough), or accept the manual step while you plan a longer-term replacement.

2. How frequently does the data need to move?

Not every data exchange justifies a real-time API. Ask: what is the cost of data being one hour old? One day old?

• A webshop order needs to reach the ERP within minutes — customers expect immediate confirmation and inventory must reflect the sale.
• A monthly financial close report can tolerate a nightly batch export.
• A product catalogue update from your ERP to your webshop probably only needs to sync once a day.

Real-time APIs are more complex and more expensive to build and maintain. Match the solution to the actual frequency requirement, not to what sounds impressive.

3. What is the volume of transactions?

If you process 20 orders a week, a well-designed manual process with clear instructions and a good checklist might genuinely be the right answer — at least for now. If you process 200 orders a day, manual entry is both a reliability risk and a staffing cost that quickly exceeds the one-time investment in an API connection.

A rough rule of thumb: if manual data transfer takes more than 2 hours of staff time per week and is expected to grow, an API integration will typically pay for itself within 6–18 months.

4. Is the data structure compatible?

Two systems can both have APIs and still be difficult to connect, because they model the same concept differently. Exact Online uses its own customer and product codes. Your FileMaker solution uses different identifiers. Your webshop assigns order numbers in yet another format. A clean integration maps these fields explicitly — and handles edge cases like a webshop customer who is a new prospect (not yet in FileMaker or Exact Online) versus an existing account.

Understanding your data model on both sides before writing a single line of integration code saves significant rework.

5. Who owns the data, and in which direction does it flow?

Every integration has a "master" — the system of record for a given data type. Typically:

• ERP (e.g. Exact Online) is master for financial data, pricing, and VAT codes.
• CRM or FileMaker is master for customer relationships, project records, and custom business logic.
• Webshop is master for online orders and customer-facing product presentation.

If you try to sync bidirectionally without agreeing on a master, you get conflicts: the ERP says a product costs €120, the webshop says €115, and you don't know which is right. Define the flow direction first.

6. What happens when the integration breaks?

APIs fail. Rate limits get hit, authentication tokens expire, the receiving system is briefly offline. A professional integration includes:

• Error logging — every failed call is recorded with enough detail to diagnose it.
• Retry logic — a failed order sync retries automatically after a short interval.
• Alerting — someone is notified when failures exceed a threshold.
• Fallback — is there a manual override process while the issue is resolved?

If your team has no capacity to monitor and maintain an integration, a simple, robust solution with good error handling beats a sophisticated one that no one watches.

A concrete walkthrough: FileMaker ↔ Exact Online

A distribution company runs its order management, project tracking, and customer history in a custom FileMaker solution. Invoices are generated in FileMaker but then re-entered manually into Exact Online for bookkeeping. This means:

• Every invoice is touched twice by a human.
• Exact Online totals don't match FileMaker totals until someone reconciles them — usually at month-end.
• Customers occasionally receive invoices with wrong amounts because the manual re-entry introduced a typo.

The Exact Online REST API lets external systems POST invoices directly into the correct ledger accounts, with line items, VAT codes, and debtor references. A FileMaker integration script (or a lightweight middleware layer) can fire this call the moment an invoice is marked "ready" in FileMaker. The result: Exact Online is updated in seconds, no human touches the data twice, and month-end reconciliation drops from a half-day task to a quick sanity check.

The decision checklist here was straightforward: high frequency (daily), growing volume, clear master (FileMaker owns the invoice, Exact Online receives it), documented API on both sides, and a staff time cost that justified the build.

A concrete walkthrough: Webshop ↔ ERP

An e-commerce company runs WooCommerce as its storefront and a mid-market ERP for inventory, purchasing, and fulfillment. Currently, an admin logs into WooCommerce each morning, exports the previous day's orders as a CSV, and imports them into the ERP by hand. Stock levels in WooCommerce are updated manually once a week.

The consequences are predictable: customers occasionally order products that are actually out of stock (because WooCommerce shows last week's inventory), fulfillment staff work from a list that's already hours old, and the admin spends 90 minutes every morning on a task that adds zero business value.

A bidirectional integration solves both flows:

1. Order sync (WooCommerce → ERP): new orders push to the ERP in real time via webhook + API call. The ERP reserves stock immediately.
2. Stock sync (ERP → WooCommerce): inventory levels update in WooCommerce every 15 minutes as the ERP processes goods receipts and fulfillments.

The critical design decision here is the master for stock: the ERP is authoritative. WooCommerce never writes a stock level back to the ERP — it only reads. This prevents the conflict scenario described earlier.

Decision checklist: does this system need an API?

Run through this before starting any integration project:

• Data is moved manually between this system and at least one other — by copy-paste, CSV export, or re-keying.
• The manual step happens more than a few times per week and is expected to grow with business volume.
• Errors caused by the manual transfer have a real cost — wrong invoices, stock discrepancies, delayed fulfillment, customer complaints.
• The system has a documented, accessible API (or a viable middleware alternative exists).
• The required sync frequency (real-time, hourly, daily) is known and proportionate to the effort of building a real-time integration.
• A clear master system of record has been agreed for each data type being synced.
• Someone owns the integration post-launch: monitoring, error handling, and updates when the upstream API changes.
• The business case holds: estimated staff hours saved × cost per hour > integration build + annual maintenance cost.

If you can check six or more of these, proceed. If you check fewer than four, dig deeper into whether the problem is really an integration gap or something else (process design, data quality, or system capability).

When is an API not the right answer?

An API is not always the correct tool. Consider alternatives when:

• Volume is genuinely low and stable. A nightly file import or a weekly manual export may cost less to maintain than a live integration that someone has to monitor.
• The system being integrated is near end-of-life. Investing in an API connection to a system you plan to replace in 18 months rarely makes financial sense. A temporary workaround and a clear migration plan is often smarter.
• The data quality is poor. If the source system is full of duplicate records, inconsistent formats, and missing fields, connecting it via API will automate the chaos. Fix the data first.
• The process itself is broken. Sometimes what looks like an integration problem is really a workflow problem. Automating a bad process makes it faster to produce wrong results. Map the process, then automate it.

Frequently asked questions

How long does it take to build an API integration? A well-scoped, point-to-point integration between two systems with good APIs (e.g. FileMaker and Exact Online) typically takes 2–6 weeks of development time, including testing and edge-case handling. Complex, multi-system integrations or those involving poor API documentation take longer. The design phase — agreeing on data flows, field mappings, and error handling — often takes as long as the build itself.

Do I need a developer, or are there no-code tools? No-code middleware platforms (Zapier, Make, n8n) work well for simple, low-volume flows with standard field mappings. They break down under high volume, complex business logic, or when you need custom error handling and monitoring. For business-critical integrations — especially those touching financial data or live inventory — purpose-built integrations maintained by a developer are more reliable.

What is a webhook, and is it different from an API? A webhook is a push mechanism: System A automatically sends data to System B the moment an event occurs (e.g. a new order is placed). A traditional API call is pull: System B asks System A "do you have anything new?" on a schedule. Many modern integrations combine both: a webhook triggers the initial notification, and an API call fetches the full record. For real-time scenarios like order sync, webhooks are usually faster and more efficient.

What should I document before starting an integration project? At minimum: the list of data types to be synced, the direction of each flow, the master system for each data type, the required sync frequency, the field mappings between systems (including how mismatches are handled), and the error notification process. This document becomes the specification your developer works from and the reference your team uses when something goes wrong later.

Our ERP doesn't have an API. What now? Options include: a middleware layer that reads database tables directly (requires database access and carries risk), a file-based integration (scheduled exports/imports — less elegant but often reliable), or replacing the ERP with one that does offer an API. The right answer depends on how central the ERP is to your operations and your timeline for modernizing your system landscape.

If you're looking at a landscape of disconnected systems and trying to figure out where to start, the decision framework above is the right first step — but the implementation details matter just as much as the decision itself. Loggix builds custom API integrations, tailored FileMaker solutions, and connections between ERP systems, webshops, and business tools, and can help you map out exactly which systems need to talk to each other, in which direction, and at what frequency — so you're solving the real problem, not just adding more complexity.