Software & Applications · Service 10

Interfaces other systems can rely on.

An API is a promise: send this, get that back, and it will keep working next year. Designing one well is mostly about restraint and documentation — the code is the easy part. We build APIs that your own front end, your customers' developers and your integration partners can all work against without asking you questions.

DocumentedVersioned Rate limited and authenticatedTested against real clients
Request · response

Anatomy

What a well-designed endpoint looks like

A worked example from a booking system. Click any endpoint — note that the shapes are predictable, the errors are useful, and nothing requires reading the source code to understand.

Endpoints

Versioning

The change that quietly breaks four integrations

Once anything consumes your API, you no longer control when it updates. Some changes are safe to ship on a Tuesday; others need a new version and a migration period. Pick a change and see who notices.

Scope

What an API project actually covers

Writing endpoints is perhaps a third of the work. The rest is what makes them usable by someone who has never spoken to you.

Design

Consistent shapes

The same field means the same thing everywhere, lists paginate the same way, and dates are always the same format. Predictability is what makes an API pleasant.

Errors

Failures that explain themselves

A machine-readable code, a human-readable message and the specific field at fault. Vague 400 responses turn every integration into a guessing game.

Auth

Keys, scopes and rotation

Tokens that can be scoped to what a client actually needs and rotated without downtime — because eventually one will leak.

Limits

Rate limiting that is honest

Clear limits, headers showing what remains, and a retry-after when exceeded. Silently throttling clients is how you lose integration partners.

Docs

Documentation generated from the code

OpenAPI written alongside the implementation so it cannot drift, with worked examples for every endpoint. Stale documentation is worse than none.

Change

Versioning and deprecation

A stated policy for what counts as breaking, how long old versions live, and how consumers are warned. Decided before the first client, not after.

Testing

Contract tests

Automated checks that the response shape has not changed unintentionally, so a refactor cannot silently break someone else's software.

Events

Webhooks where polling is wasteful

Signed, retried, idempotent callbacks so consumers are told when something happens rather than asking every minute.

Observability

Knowing who calls what

Per-client logging and latency metrics — so when someone reports a problem you can see it rather than asking them to reproduce it.

Questions

API development, answered

REST or GraphQL — which should we build?
REST for most business APIs. It is cacheable, easy to debug with ordinary tools, and every developer already knows it. GraphQL earns its complexity when many different clients need different slices of the same data and over-fetching is a real cost — a mobile app and a web app with genuinely different needs, for example.
Do we need an API if we only have one website?
Not necessarily today. But the moment you want a mobile app, a partner integration or a second front end, having one already is the difference between weeks and months. If you are building a web application anyway, structuring it API-first costs little extra at the time.
How do you handle authentication?
Depends on who is calling. Server-to-server usually means scoped API keys; user-facing clients usually mean OAuth or short-lived tokens. What matters more than the mechanism is that keys can be scoped, rotated and revoked per client without taking anything else down.
What happens when we need to change the API later?
Additive changes ship normally. Breaking ones get a new version, with the old one kept alive for a stated period and consumers warned in advance. The policy is written down at the start — after the first integration exists is too late to invent it.
Can you build an API on top of our existing system?
Usually. Older systems can often be exposed through a carefully written layer that reads their database or wraps their existing logic. That layer is also a good place to clean up naming and structure without touching what already works.
Who writes the documentation?
We do, and it is generated from the same definitions the code uses so it cannot drift out of date. You get a browsable reference with real request and response examples that a third-party developer can work from without contacting you.