API Development
Reliable, documented APIs for organisations whose systems need to exchange data or trigger each other through a stable interface, whether that means building a new one or repairing an existing one.
Sometimes the problem is the interface itself. A system has no API, or it has one that is undocumented, unreliable or too permissive to expose, and every new connection depends on whoever still remembers how it behaves.
An interface, not an end in itself
An API is useful when another system, team or partner needs a defined way to read or change something. Having endpoints is not the objective. The work is to create a stable interface with clear ownership, permissions, validation, failure behaviour and documentation, and to keep that interface operable as consumers appear.
API work is usually part of a broader integration or software development requirement. We do not create a custom API where a suitable supported vendor interface already solves the problem.
When this comes up
No suitable interface
A portal, application or partner needs data from a system that was never built to share it, and querying its database directly would be unsafe.
An existing API that cannot be operated
There is little or no documentation, authentication is shared, or a change in one place breaks callers that nobody has listed.
Errors that surface later
Bad requests are accepted and fail further along, or the API reports success when nothing was saved. Retries then create duplicates.
Typical work
Design the contract
Agree the resources, commands, permissions and error behaviour with the teams that will call the API, including how retries should be handled.
Build or extend it
Implement authentication, authorisation, validation and consistent errors. Add idempotency where a request may be repeated. Rate limits and other protective controls are added where the risk requires them.
Document and version it
Produce reference documentation that matches the running code, and a versioning approach so existing consumers are not broken without notice.
Remediate an existing API
Tighten permissions, correct error handling, add versioning and document what is already there, without unnecessarily breaking current callers.
What you end up with
A documented interface
Reference documentation that matches the running code, so other teams can build against it without asking the original developer.
Permissions and failure behaviour that are defined
Each consumer has its own credentials and scope, and errors, retries and rate limits behave in a way that is written down.
A way to change it safely
A versioning approach and a list of known consumers, so the interface can change without surprising anyone.
How a typical engagement works
01Discovery
Find the consumers and the data
We list what needs to read or change which records, who owns the underlying data, and what the current interface, if there is one, actually does.
02Contract
Agree the contract
Resources, permissions, error behaviour and retry rules are agreed with the teams that will call the API before anything is built.
03Build and test
Build and test with real callers
The API is built in stages and tested against the real consumers, including malformed requests and repeated calls.
04Handover
Document and hand over
Reference documentation, credentials, monitoring and a versioning plan are handed over so someone else can operate the interface.
05Support
Support as consumers change
After handover, the interface can be supported and versioned as consumers and requirements change.
Frequently Asked Questions
Start with a conversation
Book a free 15 minute call. Describe the problem, the systems involved and what you already know, and we will tell you plainly whether we can help and what a sensible next step looks like. There is no obligation.