Most API trouble starts long before anyone writes any code.
You feel it in small ways first. A mobile release waits because the endpoint it needs does not exist yet. A report takes a fortnight because the numbers live in three systems that have never spoken to each other. An integration with somebody else's API is fine right up until their outage becomes your Monday morning.
None of that is really an API problem. It is a design problem that surfaced as one, and it is much cheaper to fix at the specification stage than after a hundred clients are depending on the shape of your responses.
When the API is the product
In SaaS platform development the API is often the thing customers actually buy. It is what their developers integrate with, what your mobile app talks to, and what your pricing gets built on. It has to be documented, versioned and stable enough that changing it does not break somebody else's business.
When the API runs the business
In business operations software the API is connective tissue. It is what lets a quoting tool, a survey app and a finance package behave like one company rather than four spreadsheets and a lot of copying and pasting.
01Design and specification
We start from the workflow, not the schema. Event storming and story mapping with the people who will use it, then a resource model and an endpoint design that follows. You get the specification before we build against it, and you get to argue with it.
02Security and access control
Authentication, authorisation on every request, validation of anything a client sends, and encryption in transit and at rest. Security is part of the design, not a hardening pass at the end. Where it fits we use Cognito rather than rolling our own.
03Performance, caching and cost
Serverless APIs on Lambda and API Gateway scale with demand and cost nothing when idle. CloudFront caches what can be cached. We measure before we optimise, and we tell you when a change would buy speed you do not need.
04Documentation and versioning
An OpenAPI description generated from the API rather than maintained alongside it, so it cannot drift. Versioning from day one, so the release that adds a field does not break the client written last year.
05Consuming APIs you do not own
Plenty of our work is on the other side of the request: pulling data out of somebody else's system, in JSON, XML or whatever they hand back. The interesting part is what happens when they are slow, rate-limited or down, and how much of that your users should ever see.
The APIs we built are still doing the work.
The stack is usually Node.js or PHP behind AWS Lambda and API Gateway, with CloudFront in front and Cognito handling identity. We are an AWS Select Tier Services Partner and we run a Well-Architected review on every engagement, which is a large part of why the bill does not surprise anyone in month four.
Offline-first survey app
Watts Group, on HS2
Surveyors record pre-condition surveys with no signal at all. The app works offline and reconciles later.
MHM Culture Segments TagTool
A platform used by arts organisations worldwide, built from inception and still run by us.
GT World, for SRO Motorsports
A React Native app carrying live video, timing and team data to GT racing fans across every series.
Si Novi have played a crucial role in the development of Culture Segments TagTool, from its inception to what it is today. They have brought to life our vision for the product with a thoughtful and creative approach.
We work out what the API has to do before we decide what it looks like.
- 01
Specify
We sit down with the people who will use the thing and map what has to happen, using event storming and story mapping. The endpoints fall out of that. Designing them first, and finding the workflow afterwards, is how you end up with an API shaped like your database instead of your business.
- 02
Build
REST where it fits, GraphQL where the client genuinely needs to choose its own shape of data. Versioned from the first release rather than the first breaking change. Documented as we go, so the developers who consume it are not reading your source code to work out what a 422 means.
- 03
Run
We stay. Someone has to watch the error rates, keep the dependencies current and answer the phone when a consumer of your API starts behaving oddly. In most of our engagements that is still us, years after launch.
The things buyers ask us first.
Will we be locked in?
No. Everything we build runs in your own AWS account, and you get a copy of all of it, including the infrastructure definitions and the deployment pipeline. You can take it elsewhere whenever you want. An engagement that only survives because leaving is painful is not one we want.
Can you work with the API we already have?
Usually, yes. We will read it, tell you honestly what state it is in, and give you the options. Sometimes that is a rewrite. More often it is a versioned path forward.
Does it have to be on AWS?
No, though it usually is. We know AWS deeply enough to make it cheap and boring, and that is worth more to you than a stack we would be learning at your expense.
Who will actually build it?
The two founders, and the trusted collaborators we bring in around them. No account manager between you and the people writing the code, and no junior learning on your project.