TECHNOLOGY SERVICE · 11
API Development & Integration
APIs designed as products, with a specification, a version policy and documentation another team can build against without calling you. Also the reverse: consuming third-party services in a way that survives their releases and their outages.
Design the contract before the controller
The specification comes first, written in OpenAPI and reviewed with the teams who will consume it. Mock servers generated from that specification let client work start in parallel, which routinely saves weeks on projects with separate frontend and backend teams.
Resource naming, pagination, filtering, error shapes and status codes follow one published convention across the estate. Consistency is what makes the second and third integration fast.
- OpenAPI specification reviewed before implementation
- Mock server available to consumers from week one
- House conventions for errors, pagination and filtering
Versioning is a promise you keep
Once another team depends on an endpoint, breaking it is an operational incident. A stated version policy defines what counts as a breaking change, how long old versions are supported and how consumers are notified. Additive changes ship freely; breaking ones get a new version and a deprecation window with usage monitored per client.
Keys, quotas and the people using them
Authentication is chosen to match the consumer: OAuth 2.0 flows for third-party applications, signed service credentials for machine traffic, short-lived tokens throughout. Rate limits and quotas are set per client so one careless integrator cannot degrade service for everyone.
Documentation includes worked examples and a sandbox, because an API that requires a support ticket to start is not really available.
Integrations you did not write still page you at 3am
Consuming an external service means inheriting its failure modes. Timeouts, circuit breakers, retry budgets and cached fallbacks are specified per dependency, and each one gets a documented answer to the question of what your product does while it is down.
What you get
- OpenAPI specification held in your repository and reviewed by consumers
- Implemented endpoints with automated contract tests
- Published documentation with worked examples and a sandbox
- Authentication, authorisation and token lifecycle configuration
- Rate limiting, quotas and per-client usage metrics
- Version and deprecation policy, with consumer notification process
- Resilience patterns defined per external dependency
- Monitoring on latency, error rate and consumer adoption
Typical outcomes
<100ms
Median API response time we design towards
99.9%
Availability target for published endpoints
1 week
From specification sign-off to a usable mock
Stack we use
Questions
REST suits most enterprise integration, where caching, simple tooling and predictable contracts matter. GraphQL earns its complexity when varied clients need different shapes of the same data, and it can sit alongside REST rather than replacing it.
Once you have several consumers, a gateway is the cheapest place to put authentication, rate limiting and usage metrics. A single internal API can start without one, provided those concerns are not scattered through application code.
Yes. Existing endpoints are captured from traffic and code into an OpenAPI specification, inconsistencies are listed, and we agree which are worth correcting against the cost of breaking consumers.
Sandbox credentials, worked examples and a short certification checklist let a partner test before touching production. That checklist is usually what turns a multi-week onboarding into a couple of days.
Related
Next step
Start with a 20-minute call.
Tell us the roles you need filled, the system you need built, or both. You will speak to someone who has done the work, and leave the call with a route forward.