API Development and Systems Integration

Where integrations actually break

Not in the happy path. They break when the third party is down, when a field arrives null that never has before, when the same webhook is delivered twice, and when someone edits a record in both systems at once.

Designing for those cases from the start is most of the difference between an integration that runs for years and one that quietly corrupts data for a month before anybody notices.

Versioning, before you need it

An API with external consumers cannot change shape without warning. Versioning and deprecation planned at the start costs almost nothing; retrofitted after three clients depend on you, it is a project of its own.

The same applies to authentication. Getting that wrong is the expensive kind of mistake.

The APIs you do not control

Half of integration work is depending on somebody else's service. It will have rate limits you discover in production, a sandbox that behaves differently from live, and occasional breaking changes announced in a changelog nobody reads.

So we assume it will fail: timeouts on every call, retries with backoff, a queue so a five-minute outage delays work rather than losing it, and alerting that distinguishes 'their service is down' from 'our code is broken'. Those are not the same problem and should not produce the same alert.

Testing something that talks to the outside world

Integration tests that hit a live third party are slow, flaky and occasionally expensive. Tests that mock everything pass happily while the real integration is broken.

The workable middle is recorded real responses replayed in tests, plus a small set of checks that run against the actual sandbox on a schedule — so a provider changing their payload is something you find out about on a Tuesday morning rather than from a customer.

Designing the thing before building it

The cheapest hour on any API project is the one spent agreeing what the resources are and what the payloads look like, before code exists. Once two teams have built against different assumptions, reconciling them is a negotiation rather than a change.

We write the specification first and share it — an OpenAPI document you can read and argue with. Disagreements at that stage cost a conversation. The same disagreements found in integration testing cost a sprint.

Knowing when it breaks

An integration that fails loudly is a minor incident. One that fails silently corrupts data for weeks, and the cost of putting that right is far greater than the cost of building the monitoring would have been.

Every integration we build reports whether it ran, how long it took and how many records it moved — so 'nothing has synced since Thursday' is a question somebody can answer.

What we do

• API design and build in Python or Node
• Integration with CRMs, payment providers and internal systems
• Authentication, rate limiting and audit logging
• OpenAPI documentation and a working sandbox
• Taking over and stabilising an integration somebody else left behind