API Development & Integration for UK Businesses

It depends on how many systems are involved, the quality of their APIs and how much historical data needs cleaning or backfilling. A discovery sprint from £2,000 maps the systems and ends with a fixed-price quote for the build. Small, well-defined integration fixes can run on flexible hours from £20 an hour.

Often, yes — for low volumes and simple steps, no-code tools are quick to set up and cheap to run. Custom code earns its place when volumes grow, when you need proper error handling and retries, when data has to stay in your own infrastructure, or when per-task pricing starts to cost more than a build. We will tell you which side of that line you are on.

Yes. We build against HMRC’s MTD APIs, including the OAuth sign-in flow and the fraud prevention headers HMRC requires, and test everything in HMRC’s sandbox first. Production access goes through HMRC’s own approval checks, which we prepare for with you; the final decision sits with HMRC.

REST suits most public and partner APIs: simple to cache, widely understood and easy to document with OpenAPI. GraphQL suits products where several front ends — a web app and a mobile app, say — need different slices of the same data. Plenty of products use REST externally and GraphQL internally; we recommend based on who will call the API.

OAuth 2.0 or scoped API keys depending on who is calling, least-privilege permissions, rate limiting, input validation, encryption in transit and secrets kept out of the code. We test against the OWASP API Security Top 10 and log every call with enough detail to answer "who accessed what, and when" — which also supports UK GDPR accountability.

Our integrations are built to expect it: retries with backoff, queues that hold work until the provider recovers, alerts when failures pass a threshold, and pinned API versions so a provider update does not change behaviour overnight. On support, we track deprecation notices and upgrade before the cut-off date.

Yes. We start with an audit: read the code, observe real traffic where we can, and write an OpenAPI description of what the API actually does — including the undocumented behaviour your clients rely on. Then we add tests, and only then start fixing or extending it.

We agree a versioning approach up front and make additive changes wherever possible. When a breaking change is unavoidable, old and new versions run side by side with a published deprecation date, and usage logs show who is still on the old version so nobody is cut off by surprise.

Yes, through authorised Open Banking providers’ APIs — account information with the customer’s consent, and payment initiation. Whether your business needs its own permissions or can rely on the provider’s is a regulatory question for your advisers; we build to the model you choose and do not give regulatory advice.

You do: the code, the documentation, the API credentials and the cloud accounts everything runs in. We set integrations up under your own accounts with each provider, not ours, so nothing needs untangling if you bring the work in-house.