Custom Software

API development services

An API is a promise to everyone who builds on it. Good ones are predictable, well documented and don’t break people’s software when you change something.

This page is about building APIs that others use, such as the service behind your mobile app, or an interface you offer to partners and customers. If you’re trying to connect systems you already own, take a look at software integration.

An API’s design has a long life. Once a partner has built against it, changing a field name can break their product. So we spend time on the contract up front, writing an OpenAPI specification that everybody can review before development begins. It also means that front-end and mobile teams can start work against a mock while the back end gets built.

What separates a good API from a working one

Plenty of APIs work in a demo. Production ones also need clear error messages, pagination that holds up on big datasets, rate limits to protect you from a runaway client, and idempotency keys, so that a retried request doesn’t create a second order. They need a version strategy so you can evolve without breaking anyone. Security is its own discipline, and the OWASP API Security Top 10 is a good checklist, with broken object-level authorisation (one customer accessing another’s records by changing an ID) sitting at the top of it.

Problems a well-designed API prevents

Changes that break clients

Without versioning or a contract, a small server change can take your app or a partner’s system down.

Undocumented endpoints

Each new integration begins with weeks of questions, since nobody knows quite how it behaves.

Authorisation mistakes

Checking that someone is logged in isn’t the same as checking that they may see this particular record.

API services

API design

Resource modelling and an OpenAPI specification agreed before development starts.

REST and GraphQL build

Implementations with validation, pagination, filtering and consistent errors.

Authentication

OAuth 2.0, API keys and scoped tokens, with object-level authorisation tests.

Webhooks

Signed event delivery with retries, so that clients don’t have to keep polling.

Developer documentation

Reference docs, examples and a sandbox for your partners.

Monitoring

Usage metrics, rate limiting and error tracking for each client.

Where it fits

  • The back end of a mobile or web application
  • Partner and customer-facing integrations
  • Exposing an older system through a modern interface

Technology

  • OpenAPI
  • REST
  • GraphQL
  • OAuth 2.0
  • Laravel
  • Node.js
  • Redis
  • Postman
  • Kong

Sectors we think about here

API Development questions

REST or GraphQL?
REST suits most public and partner APIs, thanks to its simplicity and straightforward caching. GraphQL can be a better fit when many different clients need different data shapes from a complex domain.
How do you stop an API change breaking existing clients?
We version the API, make additive changes wherever possible, and give deprecation notice with a migration path before removing anything.
Can you add an API to an old system?
Usually. A new API layer in front of a legacy system is a common first step in modernising it.

Interested in API Development?

Outline what you need, and we will reply by email with questions or next steps.

Start a Project