Skip to content

Software Engineering

API Development

We design, build and operate the API — contract first, authorisation enforced, backwards compatibility treated as the discipline it is.

Overview

This is the delivery service, not a discussion of the technology. You bring an API you need built — a public product API developers will pay to build on, the internal service APIs holding a system together, or an integration API stitching your CRM, billing and fulfilment into something that works as one — and we design it, build it, put it into production, and run it. The distinction from a generic "we do APIs" pitch is that we own the parts that only hurt later: the contract that a dozen consumers will depend on, the authorisation checked on every object, and the versioning discipline that lets you change the thing without breaking everyone who calls it.

The uncomfortable truth about this work is that a badly-designed API is expensive to change once consumers depend on it. The day a partner or a shipped mobile app is calling your endpoint, you can no longer rename a field or tighten a validation without a deprecation window and two versions running side by side. So the money is not in typing out endpoints — that is the easy, cheap part — it is in getting the contract right before anyone builds against it. We spend real effort at the front of an engagement on the surface, the error model and the compatibility strategy, precisely because those are the decisions that are cheap now and ruinous to unwind in eighteen months.

We deliver across the styles — REST over HTTP, GraphQL, gRPC, webhooks and event-driven messaging — and we choose per boundary rather than picking a favourite and forcing everything through it. Most real systems end up using more than one. The REST-versus-GraphQL choice in particular carries genuine trade-offs with no free answer, and part of what you are paying for is a senior engineer making that call on your workload and your consumers rather than on what looked good in a conference talk.

Who it’s for — Teams who need an API that others will depend on — partners, another team, a mobile app, the public — built and operated by seniors who understand what breaking that contract actually costs.

What you get

  • A designed, documented API contract — resources or schema, operations, error model and status codes — captured as an OpenAPI or schema specification you own
  • A working API in production, built in thin vertical slices, each one authenticated, authorised and backed by real data rather than a demo
  • Authentication and per-object authorisation designed in from the first endpoint, not retrofitted after a penetration test
  • Versioning and a backwards-compatibility policy, with deprecation handled as a timeline rather than a surprise
  • The operational parts that matter under load — idempotency, pagination, rate limiting, structured errors, an API gateway where it earns its place
  • Accurate reference documentation, mock servers and, where useful, generated client SDKs, so an integrator can build without emailing you
  • Monitoring, logging and tracing shipped with the API, plus a handover so your own engineers can operate and extend it

What API Development does for you

  • Consumers who can move independently

    The entire point of an API is that the teams either side of it can change their internals, deploy on their own schedule and scale separately, as long as the contract holds. We design that contract so it genuinely decouples producer from consumer, rather than a thin wrapper that leaks your database schema and forces everyone to change in lockstep every time you do.

  • The right style for each boundary

    REST, GraphQL, gRPC, webhooks and events each solve a different problem and cost something different. Choosing well — and being willing to mix them — means your public surface stays cacheable and conventional, your service-to-service calls are fast and typed, and your asynchronous flows are actually asynchronous instead of a polling loop wearing a costume.

  • The expensive mistakes avoided early

    Getting authorisation, versioning and the contract shape right before launch is far cheaper than discovering afterwards that access control leaks data, or that you cannot change a field without breaking every consumer at once. We front-load that work because it is where a well-run API engagement either saves you years of pain or quietly creates it.

Why teams choose us for API Development

  • You are building an API other people will depend on, and you want the contract, versioning and documentation done by engineers who have felt what breaking a live contract costs — not treated as paperwork to finish after the endpoints work.
  • You have several systems that must talk to each other, and you want integration APIs designed to survive real-world failure — retries, idempotency, third-party outages — rather than a happy-path script that dies the first time a network blips.
  • You want a straight answer on API style, chosen for your workload and your clients rather than for a CV, including the honest cross-reference to when a lighter or heavier tool would serve you better.
  • You care about security beyond a login screen — authorisation enforced per object, sensible token handling, rate limiting and a monitored front door — built in from the first endpoint instead of found missing by an assessment.

What API Development includes

The concrete pieces of work this covers — scoped to what your problem actually needs.

  • Contract-first design and the OpenAPI spec

    We design the surface before writing handlers — resources, operations, request and response shapes, error models, status codes — and capture it as a machine-readable specification. That spec is the source of truth: it drives client SDKs, server stubs, mock servers and documentation, so the description of the API and its actual behaviour cannot silently drift apart, and so the hard modelling decisions are forced to the front where they are cheap to change.

  • REST, GraphQL, gRPC and event-driven delivery

    We build in whichever style fits the boundary: REST for conventional, cacheable, resource-oriented surfaces; GraphQL when many clients need different shapes of the same data; gRPC for fast, typed, internal traffic; and webhooks or a message broker where the flow is genuinely asynchronous. The skill is deciding deliberately per boundary, and being honest that GraphQL forfeits easy HTTP caching and gRPC is awkward from a browser.

  • Authentication and per-object authorisation

    We implement authentication appropriate to the consumer — OAuth2 and OpenID Connect for users and third parties, API keys or signed tokens for machines — with sensible lifetimes, rotation and scope. Authorisation is built as a deliberate layer, checked on every object against the authenticated principal in the data layer, never inferred from the fact that a request carried a valid token.

  • Idempotency, pagination and honest error handling

    The details that make an API usable under real conditions: idempotency keys so a retried write does not charge a card twice, cursor or keyset pagination that stays correct as data grows rather than offset pagination that skips and repeats rows, and structured, consistent errors with the right status codes and enough detail for a caller to know whether to retry, fix the request, or escalate.

  • Rate limiting, throttling and the gateway pattern

    A single monitored front door where authentication, rate limiting, throttling, request validation and routing live in one place rather than being reimplemented per service. Limits keyed to the client defend against both accidental hammering and deliberate abuse. We use a gateway where it earns its keep and refuse to turn it into a second monolith that every change has to squeeze through.

  • Documentation, contract testing and monitoring

    Developer experience is a deliverable, not a courtesy. We generate accurate reference docs from the spec, write the getting-started narrative a real integrator needs, and provide mock servers and example requests. We test the contract — schema validation, consumer-producer contract tests, and the error paths, not just the happy one — and instrument the API with structured logging, metrics and tracing so a "it is slow" report has an answer rather than a shrug.

Where it fits

  • Building a public product API from scratch

    An externally-consumed API developers build on — a REST or GraphQL surface with OAuth2, API keys, rate limiting, generated documentation and a strict backwards-compatibility policy. Here the contract is a product in its own right: versioned deliberately, documented honestly, and changed only with deprecation windows, because you cannot phone every consumer and ask them to update overnight.

  • A partner integration that underpins a commercial deal

    An API sitting at the centre of a relationship with a specific partner or set of partners — usually a mix of synchronous endpoints for queries and webhooks for pushing events they must react to. The engineering centres on a stable contract, authentication both sides trust, idempotent operations, and clear retry and failure semantics, because a broken partner integration is a broken business relationship.

  • A mobile-app backend that must stay stable

    The backend for an iOS or Android app, where an old app version is always in the wild and the contract has to survive release cycles you do not control. That constraint drives everything: additive changes only, careful versioning, payloads sized for mobile networks, and often a backend-for-frontend that shapes data for the app rather than forcing it into a waterfall of calls.

  • Integrating systems that were never meant to talk

    An integration API between a client’s CRM, billing and fulfilment — or out to third parties. The hard parts are rarely the endpoints; they are other people’s data models, flaky networks and failures you must survive rather than prevent. We design for idempotency, clear retry semantics, and a mix of synchronous calls and events, so it keeps working the first time a third party goes down.

How we approach API Development

We design the contract before we build the API, because the contract is the most expensive thing to get wrong. That means agreeing the resources or schema, the operations each consumer genuinely needs, the error model, the auth approach and the versioning strategy up front — and turning it into a specification that becomes the shared source of truth. From that spec we can hand you mock servers and client stubs early, so the teams who will consume the API start building against the contract before the implementation is finished, and so the hard modelling questions surface while they are still cheap to change.

Then we build in thin vertical slices — a real endpoint, authenticated and authorised, backed by real data, with the error paths and idempotency in place — running in production rather than accumulating on a branch. Because the engineers who design the API are the ones who operate it, the unglamorous disciplines are built in from the outset: rate limiting, monitoring, backwards-compatibility rules and honest error responses are not a phase-two afterthought, they are how the first slice ships.

How the engagement runs

We open with the contract and the consumers, not the framework. The first questions are which clients call this API, what they actually need from it, and what promise it is making them — because that fixes the style, the versioning strategy and the shape of the surface. We agree resources or schema, the operations each consumer needs, the auth model and the error contract, and write it down as an OpenAPI or schema specification. From that we generate mock servers and stubs, so your consuming teams can start building against the contract while we build the real thing behind it.

From there the build proceeds endpoint by endpoint in short, shippable cycles. Each slice is a real, authenticated, authorised endpoint against real data with its error paths and idempotency in place — not a happy-path stub that quietly N+1s and skips the failure cases. You see progress in a running API you can call, not a status deck. Rate limiting, pagination, generated docs and client SDKs are kept current as the contract grows, so the API is releasable at every step rather than integrated in a fraught final week.

How we architect it

We keep the API surface separate from the domain and data layers. The endpoint or resolver validates input, authenticates and authorises, and translates between the public shape and the internal model — it does not reach straight into the database with whatever the client happened to send. Welding the API shape to the table shape is how you end up unable to change either without breaking the other, so we design the contract as a deliberate façade over the domain rather than a thin veneer on the schema.

Where a gateway is warranted we use it to centralise authentication, rate limiting, routing and request validation as one monitored front door, without letting it grow into a bottleneck every change must pass through. Where the flow is genuinely asynchronous, a broker decouples producers from consumers so a slow or failed consumer does not stall the producer — accepting the eventual consistency that comes with it, where the throughput or decoupling actually warrants the trade. Across all of it, the architecture serves the contract, and the contract serves the consumers.

Security

Authorisation is where APIs are actually breached, and it is where we spend the most care. Broken object-level authorisation — an authenticated user changing an ID in a request to read or modify data that is not theirs — is consistently one of the most common and most damaging API vulnerability classes, precisely because a valid token gets mistaken for permission to reach everything. We enforce access control on every object, against the authenticated principal, in the data layer where it cannot be bypassed, and never infer it from the fact that a request authenticated successfully. Function-level and field-level authorisation get the same treatment: what a caller may do is checked, not assumed.

Around that core we build the rest of the posture deliberately. Authentication is matched to the consumer — OAuth2 and OpenID Connect for users and third parties, API keys or signed tokens for machines — with sensible lifetimes, rotation and scope. Every input is treated as untrusted and validated against the schema at the boundary. Rate limiting and throttling defend against abuse and accidental floods alike. We are careful about what error responses reveal, keep secrets out of logs and URLs, enforce transport security, and use the gateway as one place to apply and watch these controls. Security here is a property of how every endpoint is built, not a hardening pass bolted on before launch.

Signs it’s time

  • More than one client or service now needs the same capability — a web app and a mobile app, several internal services, a partner — and reaching into each other’s internals has stopped scaling
  • You are exposing something deliberately: a public product API, a partner integration that is part of a commercial deal, or a mobile-app backend whose contract must survive app-store release cycles you do not control
  • Systems that were never designed to talk now have to, and the hand-built bridge between your CRM, billing and fulfilment breaks every time a third party has a wobble
  • An existing API is fighting you — you cannot change a field without breaking consumers, a security review flagged broken authorisation, or it falls over under real load

Our working method

The organising principle is that the contract is the most expensive thing to get wrong, so it is the first thing we get right. We design it before we build, capture it as a specification that is the shared source of truth, and use that spec to generate mocks and stubs so consumers build against the agreed shape early — surfacing the costly modelling questions while they are still cheap to answer. We treat a renamed field, a tightened validation or a changed default as the breaking changes they are, and we plan additive-where-possible evolution and explicit versioning from day one rather than discovering the need for it after a partner is already live.

We build in thin vertical slices in production, and the engineers who design the API are the ones who operate it — which is exactly why the unglamorous parts are present from the first slice, not deferred. And because the style decision carries real trade-offs, part of the method is the honest call: whether REST or GraphQL fits your consumers, whether an internal boundary needs an API at all, and where a lighter approach would serve you better. We would rather talk you out of premature ceremony than bill you for it.

Technologies we build it with

Chosen per problem, not per fashion — this is the stack we most often reach for on this work.

How we deliver

  1. 01

    Discover

    We map the system, the constraints and the business it serves — including the parts nobody documented.

    Architecture brief

  2. 02

    Architect

    Decisions get made, written down and defended before a line of production code exists.

    Decision records

  3. 03

    Build

    Short cycles against working software. You see progress in the product, not in a status deck.

    Shipping increments

  4. 04

    Operate

    Monitoring, incident response and iteration. The system is alive, so the engagement is too.

    Runbooks & SLOs

What changes

  • A contract consumers trust

    A deliberately designed, documented, versioned API that partners and teams can build on independently, without being broken by your internal changes.

  • Breaches designed out

    Authorisation enforced on every object in the data layer, so a valid token is never mistaken for permission to access everything.

  • An API you can change

    A versioning and compatibility discipline that lets the surface evolve for years without a coordinated break across every caller.

Industries we serve

Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.

How pricing works

  • Fixed-scope build for a well-defined API — a public product API, a partner integration, or a mobile-app backend with a known surface — quoted once the contract and the consumers are understood, so you are not paying for scope nobody has pinned down.
  • Monthly senior engagement for evolving API work, where the surface grows with the product and you want continuity, governance and a stable versioning discipline rather than a one-off deliverable handed over and forgotten.
  • Focused audit or rescue for an existing API — an authorisation and security review, an N+1 or performance investigation, a versioning or gateway strategy, or an integration that keeps failing — priced by the assessment.

Typical timeline

  1. 01

    Contract and style design

    One to two weeks agreeing the surface, the style per boundary, the auth and versioning strategy and the error model — captured as a specification your consumers can build against before the implementation exists.

  2. 02

    First vertical slice in production

    Two to three weeks delivering real endpoints end to end, authenticated and authorised, with idempotency, structured errors and monitoring in place, proving the contract against real data and real failure cases.

  3. 03

    Iterative build-out

    Endpoint-by-endpoint delivery of the rest of the surface in short cycles, each slice shippable, with rate limiting, pagination, generated docs and client SDKs kept current as the contract grows.

  4. 04

    Hardening and handover

    A security review focused on object-level authorisation, load testing against N+1 and chattiness, a versioning and deprecation policy in place, and documentation so your team can own, operate and extend the API.

Why teams choose us for API Development

  • Senior engineers only

    APIs are easy to stand up and easy to get wrong — the authorisation holes, the N+1 traps, the versioning mistakes that only bite once a consumer depends on you. The people designing your contract have run APIs in production and watched these decisions age. No juniors practising broken access control on your project.

  • We operate what we build

    We run the APIs we ship, so the parts that matter under load — idempotency, rate limiting, monitoring, backwards compatibility — go in from the start rather than after the first outage or breach. We optimise for the years a public or partner contract has to stay stable, not for a demo that looks clean on an empty database.

  • Honest about style and scope

    REST versus GraphQL, gRPC versus events, and whether an internal boundary needs an API at all are real decisions with real trade-offs, and we make them on your workload rather than on fashion. If a lighter approach serves you better, we will say so before you commit to a heavier one.

  • Contract discipline as a first-class deliverable

    Because a badly-designed API is so expensive to change once consumers depend on it, we treat the contract, its documentation and its versioning as core engineering rather than paperwork. That discipline is the difference between an API people build on with confidence and one they quietly learn to route around.

How to engage us

Three ways to work with us on this — chosen to fit the problem, not our margin.

Related services

Part of Custom Software Development. Other work we do alongside this.

Related terms

Common questions

How is this different from your API technology page?

The technology page explains APIs as a subject — the styles, the trade-offs, when the approach is right. This is the delivery service: the engagement in which we design your contract, build the API in production, secure it, version it and operate it, then hand it over. If you want to understand the landscape, read the technology page; if you want an API built and run by seniors, this is that service.

REST or GraphQL — which should we build?

It depends on your consumers and your boundaries, and the honest answer is often more than one. REST suits conventional, cacheable, public and resource-oriented surfaces and gets HTTP caching for free. GraphQL earns its complexity when many different clients need different shapes of the same data, at the cost of harder caching and more server work. gRPC is excellent for fast, typed, internal traffic but awkward from browsers. We choose per boundary on your actual workload, and we will show you the trade-offs rather than ask you to take our word for it.

We already have an API — can you fix it rather than start over?

Usually, yes, and a full rewrite is rarely the right first move. We start with an assessment: where authorisation is enforced and where it is merely assumed, where the N+1 and chattiness problems live, whether the versioning strategy exists at all, and whether the contract can be evolved or has painted you into a corner. From there we sequence fixes — a security pass on object-level authorisation, a gateway or rate-limiting layer, a versioning discipline — so the API improves without a big-bang replacement that halts everything depending on it.

How do you stop a change from breaking the people who depend on us?

By treating the contract as a promise from day one. We make additive, non-breaking changes wherever possible — new optional fields and endpoints do not break existing consumers — and reserve explicit versioning for changes that genuinely cannot be made compatibly. When a break is unavoidable, we run old and new side by side with a real deprecation timeline, not a surprise. This matters most for public and partner APIs, where you cannot ring every consumer and ask them to update, which is exactly why getting the contract right early is worth so much.

What does handover look like — are we dependent on you afterwards?

No. You own the specification, the code, the repositories and the accounts throughout, and the handover is a deliverable in its own right: documentation, the monitoring and runbooks, and enough of a walkthrough that your own engineers can operate and extend the API without us. Many clients keep us on a monthly engagement for continuity and governance as the surface grows, but that is a choice, not a lock-in. An API only you understand is a liability, and we do not build those.

Let’s talk about API Development.

Tell us what you’re building or fixing. A senior engineer reads every enquiry and replies within a business day.

Prefer to book a call?Or email [email protected]

Two fields required. We reply to real enquiries — no list, no sequence.