Skip to content

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.

Blue network cables plugged into a patch panel

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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
Talk it through on a call

How we approach it

The steps between a first call and go-live.

  1. 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.

  2. 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.

  3. 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.

  4. 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

Questions

Questions about this service.

Ask us directly
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.