Web & Software
API Development
APIs designed to be consumed by someone who has never met you — versioned, documented, predictable in failure, and instrumented so you can see what callers are actually doing.
Design before implementation
We agree the contract first — resources, shapes, error format, pagination, versioning, rate limits — and write it as an OpenAPI specification before any endpoint is built. Consumers can start against a mock while the implementation catches up, and the specification cannot drift because the code is generated from it.
Integration is where projects actually fail
Connecting to someone else's API is easy on the happy path and unbounded work on the unhappy one. Rate limits, partial failures, duplicate deliveries, silent schema changes, expired credentials. We design for those from the start — idempotency keys, exponential backoff, dead-letter queues and alerting — so an upstream outage is a delay rather than lost data.
What the engagement includes
API design
OpenAPI contract, resources, errors, pagination, versioning.
Implementation
REST or GraphQL with authentication and rate limiting.
Third-party integration
Payments, logistics, CRM, ERP, messaging.
Reliability
Retries, idempotency, dead-letter handling, circuit breakers.
Documentation
Generated reference plus the prose that explains the why.
Monitoring
Latency, error rates, per-consumer usage and alerts.
Technologies we use
Frequently asked questions
REST or GraphQL?
REST for most public and partner APIs — it is cacheable, universally understood and simpler to operate. GraphQL when you have many varied clients pulling different shapes of the same data and over-fetching is a real cost. Using both in one system is legitimate and common.
Can you integrate two systems that were never meant to talk?
That is a large share of what we do. Where there is no API we work with exports, webhooks, scheduled synchronisation or, occasionally, careful scraping — always with reconciliation so you can prove the two sides agree.
How do you secure an API?
Authentication appropriate to the consumer, authorisation checked per resource rather than per route, rate limiting, input validation at the boundary, and logging that captures enough to investigate without storing what it should not.
Do you provide a sandbox for our partners?
Yes — a sandbox environment with seeded data and separate credentials is standard for any API with external consumers.