API Development & Integration
Integrations that keep your systems in step, and APIs partners can build on.
We connect the platforms your business runs on and build the APIs your customers and partners integrate with. The contract is agreed before any code, and every integration is monitored so a failure is caught before someone has to re-key a day's orders.
What you end up with
- Stop re-keying data between systems and then reconciling the differences at month end
- Give partners and customers an API a developer can integrate in days without ringing you
- Replace the brittle scripts nobody owns with integrations you can see and monitor
- Move orders, payments and records between systems in near real time
Most projects start with a fixed-price discovery, so you have a scoped plan and an estimate in hand before you commit to a build.

Overview
Where business software usually breaks
Nearly every operational problem we're asked to look at turns out to be an integration problem. The ERP and the web shop disagree about stock, or the CRM never hears about the invoice. A nightly CSV job fails silently on a bank holiday and nobody notices until Tuesday. The scripts holding it all together were usually written in a hurry by someone who has since left, and nobody is sure what they do when they fail.
We treat an integration as proper software. That means an agreed contract, idempotent handling, retries and dead-letter queues, alerts that a person reads, and documentation. For your own APIs, whether public, partner or internal, we design contract-first with OpenAPI, so clients, docs and tests are all generated from the one spec. Then we version them, so you can change things without breaking the people who depend on you.
What's included
The kinds of work this covers.
- 01
Contract-first API design and build
REST with OpenAPI, or GraphQL where federation earns its keep. The schema is agreed before code, clients and docs are generated from it, and auth, pagination and errors work the same way on every endpoint.
- 02
Enterprise systems integration
ERP, CRM, accounting, WMS and HR platforms (SAP, Dynamics, NetSuite, Salesforce, HubSpot, Xero, Sage) connected with field mapping, validation and a reconciliation report you can audit.
- 03
Payments, EDI and B2B connectivity
Stripe, Adyen and open banking. EDI document exchange with retailers and carriers, and the supplier and customer feeds that used to arrive as a spreadsheet attached to an email.
- 04
Event-driven architecture and webhooks
Queues, streams and outbound webhooks with signing, retries and delivery logs, so systems react to a change when it happens instead of polling or waiting for the nightly batch.
- 05
Partner and public APIs
Developer portals, API keys and OAuth, rate limiting, usage analytics and a versioning policy. Other companies build on this part of your product, so it gets the same care as anything a customer sees.
- 06
Integration platform review
Straight advice on when an iPaaS such as Workato, Make or Azure Logic Apps is the right answer, and when custom code will be cheaper and more reliable over five years.
Is it right for you?
A good fit if
- Staff spend hours a week moving data between systems by hand, or fixing what a script broke overnight
- You need to give customers, partners or a marketplace an API
- A new ERP, e-commerce or CRM platform has to talk to everything you already run
- Your integrations exist, but nobody can explain them and nobody knows when they fail
- You want nightly batch jobs replaced with something closer to real time
How we approach it
The steps between a first call and go-live.
Map the systems and the data
We go through each system and work out which one owns which record, what moves where and how often, and what happens today when it goes wrong. You get a data flow map and a prioritised list of integrations at the end.
Design the contracts
OpenAPI or event schemas agreed with every consumer, covering field mapping, validation rules, idempotency and what an error looks like. Mocks mean front-end and partner teams can start before the back-end is finished.
Build with failure in mind
Retries, dead-letter queues, replay tooling and reconciliation reports. Contract tests run in CI, so a change on either side gets caught before it reaches production.
Operate and evolve
Dashboards and alerts for every integration, a versioning and deprecation policy for your APIs, and a support arrangement, so when something fails there is a named person whose job it is to fix it.
Deliverables
What you'll have at the end.
- Systems and data flow map with integration priorities
- OpenAPI or GraphQL specifications and generated client libraries
- Production integrations with retry, replay and reconciliation tooling
- Developer documentation, and an API portal where it's needed
- Monitoring dashboards and alerting for every integration
- Versioning policy and runbooks, then hand-over or ongoing support
Typical stack
The tools we tend to use for this.
- TypeScript
- Node.js
- REST / OpenAPI
- GraphQL
- .NET / C#
- PostgreSQL
- Redis
- Kafka
- AWS
- Grafana / OpenTelemetry
- Playwright
Related work
Projects that used this service.
Questions
Questions about this service.
Should we use an integration platform or build custom?
Both are reasonable. iPaaS tools are quick for simple, low-volume flows between mainstream SaaS products. Custom code wins when volumes are high, the logic is complicated, or you need full control over failure handling and cost. We'll recommend whichever will cost less to run and fail less often over the long run, and we often end up using both.
How long does an integration project take?
A single well-defined integration usually takes two to six weeks. A programme connecting a new ERP or e-commerce platform to everything you already run is more often three to six months. Discovery gives you a phased plan with an estimate for each piece.
How do you deal with systems that have poor or no APIs?
It happens a lot, especially with older ERPs and industry-specific software. The options are database-level integration, file exchange with validation, a vendor connector, or in some cases screen automation as a stopgap. Each has trade-offs and we'll spell them out before you choose.
How do you version an API without breaking existing users?
Additive changes by default and an explicit new version for breaking ones, with a published deprecation policy and usage analytics so you know who's still on the old version before you turn it off.
Can you document and stabilise integrations we already have?
Yes. We start by mapping what's there and adding monitoring so failures become visible, then replace the most fragile pieces first. You don't have to rebuild everything at once.
Related services
Industries

