API integrations for businesses using spreadsheets, CSVs and legacy systems

The reality of most Australian SMEs

A legacy ERP that can only export CSV at midnight. A CRM someone half-adopted. Finance on one system, ops on another, marketing on a third. Someone in the middle is holding the whole thing together with email rules and a diary reminder. Sound familiar?

You don't have to replace anything to start

Modern API integration services don't require green-field systems. A good integration layer reads what the legacy system produces — even if that's a CSV on an FTP server — and exposes it as clean API events to the rest of the business.

The four patterns we actually use

• CSV-to-API bridge. A scheduled worker picks up exports, validates them, and pushes the data into downstream systems via their API.
• Database change capture. Where we can read the legacy DB directly, we detect changes (timestamps, triggers or log-based CDC) and stream them out.
• Webhook shim. For systems that can send an HTTP call but nothing modern, we receive the call, normalise the payload, and fan it out.
• Queue in the middle. A durable queue (SQS, Azure Service Bus) sits between old and new — so slow legacy systems never take down the modern ones.

What "done" looks like

• Orders flow from the legacy system into the CRM automatically, with retry and alerting.
• Finance gets a daily reconciliation report instead of three people copy-pasting.
• The legacy system can be replaced on a slow timeline — because nothing else depends on its exact shape anymore.

For a worked example of the same philosophy applied end-to-end, see the BI Sense case study and the Furniture Court case study.

What to avoid

• Direct-to-direct integrations. System A hitting System B's API directly. Fine until A goes down. Use a queue.
• No idempotency. Re-running a failed job shouldn't create duplicate orders.
• No observability. If you can't see failures, they don't exist until the finance team complains.