API development & integrations
Connecting systems that were never designed to talk to each other — including the awkward ones with a SOAP endpoint, a nightly file drop, and nobody left who understands it.
Integrations fail quietly, which is the problem
A broken interface rarely announces itself. A sync stops at 2am, and nobody notices until a customer asks where their order went, or a finance report is wrong at the end of the month and the reconciliation takes two days.
The usual cause is an integration written for the happy path. It assumed the other system would always be available, always return the expected shape, and never send the same event twice. All three assumptions fail eventually, and by then the wrong data has propagated.
Building these properly means the boring things: retries with backoff, idempotency so a replayed message does no damage, dead-letter queues, reconciliation jobs that detect drift, and alerting that tells a person before it tells a customer.
What we build
Public and partner APIs
REST or GraphQL interfaces with versioning, authentication, rate limiting and documentation that reflects the current behaviour rather than last year's.
Third-party integrations
Payment providers, CRMs, ERPs, shipping carriers, accounting systems, marketing platforms — including the ones with poor documentation and a four-day support turnaround.
Legacy system bridges
SOAP endpoints, fixed-width files, SFTP drops, database-level integration and screen automation where genuinely no interface exists. We will be honest about how fragile each option is.
Event-driven pipelines
Webhook receivers and message queues with idempotency, ordering guarantees where they matter, and dead-letter handling so a poison message cannot stall the queue.
Reconciliation and alerting
Scheduled comparison jobs that detect divergence between systems and alert on it, because silent drift is what makes integration failures expensive.
Sandbox and contract testing
Tests that run against recorded responses so a third party's outage does not fail your build, and contract tests that catch their breaking changes early.
Typical stack
Chosen per project, not by habit. If your team already runs something that works, we use it.
- Protocols
- REST
- GraphQL
- webhooks
- SOAP
- SFTP
- gRPC
- Messaging
- RabbitMQ
- AWS SQS and EventBridge
- Kafka where volume warrants it
- Reliability
- idempotency keys
- exponential backoff
- dead-letter queues
- circuit breakers
- Documentation
- OpenAPI
- generated client libraries
- Postman collections
How an integration project runs
We map the failure modes before writing the happy path. What happens when the other system is down, slow, or returns something unexpected is the design, not an afterthought.
- 01
Discovery
What each system can actually do, what its real rate limits are, and where its documentation is wrong. Usually at least one unpleasant surprise, better found now.
- 02
Build
Interface built with error handling, retries and observability from the first commit rather than added after the first incident.
- 03
Parallel run
Running alongside the existing process without acting, so discrepancies surface before anything depends on it.
- 04
Monitor
Alerting on failure rate, latency and reconciliation drift, routed to whoever is on call.
Common questions
The system we need to connect to has no API. Now what?
There is usually a path — a database replica, a file export, a partner endpoint the vendor does not advertise. Failing all of that, browser automation against the interface your staff use. It works, it is fragile, and we will tell you plainly what it will cost to maintain before you choose it.
How do you handle rate limits?
Request queuing with backoff, batching where the API supports it, and caching to avoid asking twice for the same thing. We measure the real limits during discovery, because published limits are frequently wrong.
What if the third party changes their API?
Contract tests run against their sandbox catch breaking changes before your users do, and we subscribe to their deprecation notices. Version pinning where they offer it. Nothing removes the risk entirely — a vendor can still break things without notice — but this reduces it to a fixable morning rather than a week.
Can you make our integrations faster?
Often, and usually by removing work rather than adding infrastructure: batching, caching, moving synchronous calls into background jobs so a user is not waiting on a third party. We measure before changing anything.
Do you document what you build?
OpenAPI specifications for anything we expose, plus written runbooks covering what to do when an integration fails. Both live in your repository, and both are part of the deliverable rather than an extra.
Start with a scoping call.
Thirty minutes, no obligation. If we are not the right fit we will tell you on the call rather than after a proposal.
Related services
Web application development
Portals, internal tools, dashboards and SaaS products. Built to be fast on a mediocre connection, operable by …
Legacy system modernisation
The system still works, nobody wants to touch it, and the person who wrote it left in 2019. We replace systems…
Cloud & DevOps
Migration without a big-bang cutover, infrastructure defined in code so environments are reproducible, and pip…