How APIs connect modern business systems

Your sales team closes a deal in the CRM, and then someone re-types the whole order by hand into the ERP. Your webshop fires off a hundred orders on a busy Friday, and by Monday morning a warehouse employee is still copy-pasting them into your inventory system. You know the systems should talk to each other — but they don't, and the gap is filled by human effort, spreadsheets, and quietly accumulating errors. This article explains exactly how APIs close that gap: what they are, how they work in practice, and what you need to think through before you connect anything.

What is an API, really — and why does the definition matter?

API stands for Application Programming Interface. Strip away the jargon and it means: a structured, agreed-upon way for two software systems to exchange data and trigger actions without a human in the middle.

Think of it as a contract between two applications. System A says: "If you ask me for a customer record in this exact format, I will send it back in this exact format." System B agrees to ask in that format, and to handle the answer. The contract is the API.

What makes this matter for your business: once that contract is in place, data moves automatically, instantly, and consistently — no re-typing, no copy-paste, no "I thought you already updated that."

Why do disconnected systems cause more damage than most companies realise?

The obvious cost is wasted time. But the hidden cost is trust. When people know the data in System A probably isn't the same as in System B, they stop trusting both. They build shadow spreadsheets. They pick up the phone to double-check. They delay decisions because they're not sure which number is right.

A concrete example: an order gets entered into FileMaker by the sales team, and then re-typed by hand into Exact Online — every single order, every single day. Each re-type takes three minutes. At fifty orders a day, that's two and a half hours of pure duplicate work, plus a realistic error rate of around 1–2%. One wrong price or quantity per hundred orders might seem small — until it's a €4,000 invoice that goes out wrong.

Multiply that across your CRM, your planning tool, your webshop, and your logistics partner, and the real cost of disconnected systems becomes visible.

How does an API integration actually work, step by step?

Most modern business software — Exact Online, Shopify, HubSpot, Microsoft 365, and many others — exposes a REST API. Here is what a working integration looks like in practice:

1. Authentication: System A proves its identity to System B, typically using an API key or OAuth token. This is the "handshake" that says: I am allowed to ask you things.
2. Request: System A sends an HTTP request to a specific endpoint — a URL that represents a resource, like /api/v1/orders/12345. The request specifies what it wants: read a record, create a record, update a field, delete an entry.
3. Response: System B processes the request and sends back a structured response, almost always in JSON format. That response contains the data, plus a status code (200 = OK, 404 = not found, 401 = not authorised, and so on).
4. Processing: System A reads the response, maps the fields to its own data structure, and stores or acts on the result.
5. Error handling: If something goes wrong — a timeout, a validation failure, a rate limit — a well-built integration logs the error, retries if appropriate, and alerts someone if it cannot recover automatically.

This cycle can happen in real time (triggered the moment a record changes) or on a schedule (every fifteen minutes, every hour, every night). The right choice depends on how time-sensitive the data is.

FileMaker and Exact Online: a real-world integration scenario

A wholesale distributor runs their sales workflow in a custom FileMaker application — quotes, orders, customer history, margin calculations. Their accounting and invoicing live in Exact Online. For years, the handoff was manual: the sales coordinator exported a CSV from FileMaker every afternoon and imported it into Exact.

After building an API integration:

• When a sales order is marked "confirmed" in FileMaker, a script calls the Exact Online API and creates the corresponding sales order automatically.
• The Exact invoice number is written back into the FileMaker record, so the sales team can see invoice status without leaving their own tool.
• Payment status from Exact is synced nightly back to FileMaker, so account managers know which customers have outstanding balances before they call.

The result: the afternoon CSV routine is gone. Invoice errors dropped sharply. And the sales team stopped asking the finance team "has that been invoiced yet?"

Webshop to ERP: where integration pays off fastest

E-commerce is where manual data entry hits its ceiling hardest. A webshop can generate hundreds of orders in a single day during a promotion. No team can process that volume by hand without errors and delays.

A typical webshop-to-ERP integration handles:

• Order sync: every confirmed order in Shopify (or WooCommerce, Lightspeed, etc.) is created as a sales order in the ERP automatically.
• Stock sync: inventory levels in the ERP are pushed back to the webshop, so customers cannot order products that are out of stock.
• Customer sync: new customers created in the webshop are added to the CRM or ERP customer master, without duplicates.
• Shipping status: once the ERP or warehouse system marks an order as shipped, the webshop updates the order status and triggers the customer email.

The integration runs continuously. The operations team monitors exceptions — orders that failed to sync because of a missing product code, for example — rather than processing every single order by hand.

CRM and planning tool: the integration that saves sales and operations both

A deal is won in the CRM. Someone then emails the planning team. The planning team creates a project in their tool by hand, re-entering the customer name, the scope, the deadline. Two weeks later the CRM still shows the deal as "won" with no project reference, and the planning tool has a project with no link back to the original deal.

When CRM and planning tool are connected via API:

• A deal moving to "Won" in the CRM automatically creates a project in the planning tool, pre-filled with the customer, deal value, and agreed scope.
• The project ID is written back to the CRM deal, so anyone looking at the deal can jump straight to the project.
• Status updates in the planning tool (project started, delivered, invoiced) are reflected back in the CRM, keeping account managers in the loop without manual updates.

This is the kind of integration that makes both the sales team and the operations team say: "I don't know how we lived without this."

What types of API are you likely to encounter?

Not all APIs work the same way. The most common types in business software:

• REST (Representational State Transfer): the dominant standard today. Uses standard HTTP methods (GET, POST, PUT, DELETE), returns JSON. Most modern SaaS tools offer REST APIs. Exact Online, Shopify, HubSpot — all REST.
• SOAP: an older XML-based standard, still common in legacy ERP systems, government services, and financial institutions. More verbose and rigid than REST, but well-defined.
• GraphQL: a newer approach where the client specifies exactly what data it needs, reducing over-fetching. Increasingly common in modern platforms.
• Webhooks: not a request-response API, but a push notification. Instead of System A asking System B "do you have anything new?", System B calls System A the moment something changes. Useful for real-time triggers (payment confirmed, order shipped).

In practice, most business integrations combine REST APIs with webhooks: webhooks for real-time triggers, REST for reads and writes.

What should you check before building an API integration?

Not every integration project goes smoothly. These are the questions worth answering before you write a single line of code:

Technical readiness checklist

• Does the target system have a published, documented API? (Not all software does — some older systems only offer file exports.)
• Is the API REST, SOAP, or something proprietary? Do you have the skills in-house to work with it?
• What authentication method does it use — API key, OAuth 2.0, basic auth? Is token refresh handled?
• Are there rate limits? (Exact Online, for example, limits the number of API calls per minute — important for high-volume syncs.)
• Is there a sandbox/test environment you can build and test against without touching live data?
• How are errors and failures surfaced and logged?
• What happens to data that is created during a sync outage — is there a queue or will it be lost?

Data and process readiness checklist

• Are the data models compatible? (A "customer" in your CRM might have different required fields than an "account" in your ERP.)
• Who owns master data? If a customer address changes in both systems at the same time, which one wins?
• Are the existing records in both systems clean enough to sync? Duplicate customer records or missing product codes will cause failures.
• Is there a clear "source of truth" for each data type — orders, customers, products, invoices?
• Who is responsible for monitoring the integration and handling exceptions after it goes live?

How do you handle errors and keep integrations reliable?

Every integration will eventually encounter an error. The question is not whether — it is when, and whether your integration handles it gracefully.

Best practices from production integrations:

1. Log everything: every API call, every response, every error. When something goes wrong at 2am, you want a trail.
2. Build retry logic: transient errors (network timeout, temporary rate limit) should trigger an automatic retry after a short wait, not an immediate failure.
3. Dead-letter queue: records that cannot be synced after several retries should go into a holding queue for manual review, not be silently dropped.
4. Alerting: if the integration has not synced successfully in X minutes, someone should get an email or a Teams/Slack notification — not discover the problem when a customer calls.
5. Idempotency: design your sync so that processing the same record twice produces the same result, not a duplicate. Use unique identifiers from the source system to check whether a record already exists before creating it.

Frequently asked questions about API integrations

Do both systems need to have an API for this to work? Generally yes — but there are workarounds. If a system does not have an API, it may offer file-based exchange (CSV, XML) that can be automated with a scheduled process. This is less elegant and less real-time, but it is far better than manual data entry.

Is an API integration a one-time build or ongoing maintenance? Both. The initial build is a project. But APIs change over time — vendors release new versions, deprecate old endpoints, change authentication methods. A production integration needs periodic review and updating. Plan for that cost from the start.

How long does it take to build a typical integration? A straightforward one-directional sync (orders from webshop to ERP, for example) can be built and tested in a few days to a few weeks, depending on the complexity of the data mapping and the quality of both APIs. A bidirectional integration with conflict resolution, error handling, and monitoring will take longer. Rushing this work creates reliability problems later.

What about integration platforms (iPaaS) like Zapier or Make? For simple, low-volume connections between well-supported SaaS tools, these platforms can work well and are faster to set up. Their limitations show at scale, with complex data transformations, or when one of the systems is a custom application like a FileMaker database. At that point, a purpose-built integration is more reliable and maintainable.

Is our data safe when it travels through an API? Security depends on implementation. Key requirements: all API traffic should be encrypted (HTTPS/TLS), access tokens should be stored securely and never hardcoded, and each integration should use the minimum permissions necessary (the principle of least privilege). Always check the security documentation of both systems before going live.

---

If your business is running on systems that don't talk to each other — whether that's a FileMaker application that doesn't connect to your accounting software, a webshop that requires manual order processing, or a CRM that never knows what the operations team is doing — API integration is almost always the right answer. Loggix builds these connections as part of broader custom software work: from mapping the data flows and defining the source of truth, to building the integration, monitoring it in production, and keeping it running as your systems evolve. If you're not sure where to start, a short consultancy session to map your current system landscape is often the clearest first step.