APIs that let your systems stop copying data by hand

Why APIs decide what your software can become

Most businesses do not set out to build an API. They set out to build a website, and then a mobile application, and then to connect a supplier system, and each time somebody asks whether the existing software can share its data. If the answer is no, every new requirement means either duplicating logic or copying information manually, and both choices get more expensive every year.

We build APIs with Django REST Framework, which handles serialisation, authentication, permissions, filtering, pagination and rate limiting using patterns that any competent developer recognises immediately. That familiarity matters, because an API is usually consumed by somebody other than the team that wrote it, sometimes years later.

The design work that matters happens before any code. What are the resources, and do they match how the business thinks rather than how the database happens to be structured? What can each kind of caller see and change? How are large collections paged? What does an error look like, and does it explain enough for the caller to act? How will this change in two years without breaking everything already using it?

Authentication, permissions and rate limits

Every API needs a clear answer to who is calling and what they may do. We implement token based authentication for mobile applications, key based access for server to server integration and session authentication where a browser is involved, choosing based on what is actually calling rather than applying one pattern everywhere.

Permissions are enforced on every endpoint, not merely on the ones somebody remembered. A caller should be unable to reach records outside their organisation even if they guess the identifiers, and we test that deliberately. Rate limiting protects the system from a partner integration with an enthusiastic retry loop, which is a far more common cause of outages than any deliberate attack.

Versioning, documentation and not breaking people

The hardest part of running an API is changing it without breaking the software already depending on it, especially mobile applications where old versions remain installed for months after an update is released. We plan for that from the start, adding fields rather than renaming them where possible, versioning when a genuine break is unavoidable, and keeping older versions working for a stated period.

Documentation is produced as part of the work rather than promised afterwards. Whoever integrates with your API, whether that is your own future developer or a customer technical team, should be able to see the available endpoints, the expected parameters, example responses and the meaning of each error without needing a meeting.

Integrating with services you already use

The other half of this work is consuming other people interfaces. We connect systems to payment providers, email delivery services, message gateways, accounting packages, mapping and location services, calendar systems, document storage and industry specific platforms. The engineering care here goes into the failure paths, because external services are occasionally slow, occasionally down and occasionally return something unexpected. Integrations that assume everything always works are the ones that wake people up at night.