API integration between your business tools

For moving information that has been entered once. In most small businesses the same order is re-keyed three times: into the order management system, into the accounts, then into the tracking spreadsheet. Every re-keying costs time and introduces a discrepancy: after a few weeks nobody knows which figure is the right one.

An API integration removes that copying. Your programs exchange directly: an accepted quotation creates the order, the order feeds the invoicing, the invoice lands in the accounts, and the dashboard updates itself. The signal that justifies the work is always the same — the time spent copying, measured in hours per week.

The ones you already have, in the vast majority of cases. Order management and ERP, accounts software, CRM, online shop, till, electronic signature tools, email and calendars, shared file spaces, software specific to your sector. We start from what exists rather than proposing yet another platform: it is the best way to avoid a project that adds work instead of removing it.

The first job is to establish, for each tool, what it can expose: a documented API, an automatable export, an existing connector, or nothing at all. That answer shapes the whole costing, far more than the number of flows to be built.

That happens often, and it is not a deal-breaker. Three routes exist, in order of preference. Automated file exchange: a scheduled export, dropped in the right place, picked up and checked automatically — less elegant than an API, but robust and easy to diagnose. An existing connector, where the vendor or a third party offers one: we check what it actually covers before settling on it. Interface automation as a last resort, reserved for entirely closed software: it is the most fragile option, and we say so before proposing it.

When none of the three stands up, the honest conclusion is sometimes that the tool has to change — or that the flow has to be given up. We prefer to say that at the scoping stage rather than deliver a bridge that will break at the first update.

A bridge that works on the day it is delivered proves nothing: what counts is how it behaves on the day one of the programs is unavailable. We always design in four safeguards. Logging: every exchange is traced, so that a discrepancy can be diagnosed in minutes. Error recovery: an exchange that fails is retried, then set aside without blocking the rest. Protection against duplicates: the same event replayed does not create two orders. Alerting: somebody is told when a flow stops, rather than waiting for an accountant to find out at the end of the month.

Those four points account for a significant share of the work. They are also what separates a professional integration from a script running in a corner that nobody dares touch.

It is costed like a development project, in stages. The costing breaks down as follows: scoping and mapping the flows, with the first conversation still free; a simple bridge between two tools that both expose an API; a full integration with historical data migrated and a tracking dashboard; maintenance and monitoring of the flows, per month.

What moves the figure comes down to three things: the quality of the interfaces your software exposes, the volume and frequency of the exchanges, and the level of checking required on the data being passed. The number of flows, oddly enough, counts for very little.