API Integration
What we've learned so far
Software is only as useful as the systems it can reach. An integration is what turns separate tools into one operation: payments that reconcile, shipping labels that generate themselves, a CRM that reflects what actually happened rather than what someone remembered to enter. The gain is not convenience. It is removing the manual handoffs where information gets lost, delayed or entered twice.
It needs doing properly because integrations are easy to demonstrate and hard to operate. Networks time out, vendors deprecate endpoints, rate limits arrive without warning, and a retry that is not idempotent will cheerfully create the same order twice. We design for the second attempt before the first one works, and we build the queue, the retry policy, the dead letter handling and the alert as part of the job rather than as a later phase. The alternative is a client discovering a three-day gap while reconciling their accounts. An integration is not finished when data moves. It is finished when someone can tell it is still moving without reading logs.
Generating a connector against a documented API is now quick, which has raised the volume of integrations that work in a demo and fail against real data. It has not made the hard part easier. Which vendor to depend on, what happens when they change something, how much of their unreliability you can absorb before it becomes your customers' problem, and who is accountable when it breaks outside working hours. Where an API is genuinely poor we say so and price the workaround openly, rather than absorbing it quietly and missing the date.
What this can involve
ETL and Data Pipelines
ERP Integration Services
Workflow Automation with n8n and Make
API Design and Development
How we work
Map systems and records
Which records, in which direction, how often, and what has to happen when both sides change the same thing. This is the part that gets skipped and then causes everything else.
Build the integration and the recovery
The connection itself, plus the retries, queuing and reconciliation that keep it consistent when something breaks at three in the morning.
Test against real conditions
Live data, rate limits and the edge cases the documentation does not mention, rather than a clean sandbox that behaves.
Make it visible
Logging and alerts so a failed sync surfaces immediately, rather than being discovered a fortnight later through a customer complaint.
Where this isn't the right fit
If both systems have a supported connector that does what you need, use it. Off-the-shelf integrations are cheaper to run and somebody else maintains them when an API changes. Custom work is for the cases where the standard option genuinely does not cover the logic.
If the data on either side is inconsistent, integration will move the problem faster rather than solve it. Fix the source first. And if what you actually need is a one-time transfer rather than an ongoing sync, that is data migration work and it costs considerably less.
