Delivery and product
Stop treating each integration as a project
When every partner, customer and internal team integrates differently, each new connection becomes a project. We set one API standard, a gateway, contract tests and a developer portal.
- Duration
- 6 to 14 weeks
- Model
- Design and build
- Output
- API standard, gateway and developer portal
Signs your integrations need a platform
Integrations rarely fail because of one bad API. They fail because there is no shared way of building them.
- Each new partner integration is estimated, staffed and delivered as a separate project.
- Two APIs in the same company use different naming, error formats, pagination and authentication.
- The API documentation is a wiki page last updated two releases ago, so partners ask your engineers directly.
- A change to one service breaks a consumer that nobody knew existed.
- Authentication, rate limits and logging are implemented differently in every service.
- Nobody can say which API versions are still in use, or by whom.
- Webhooks are retried by hand when a partner’s endpoint is down.
A standard, enforced by tooling
Inconsistent APIs are not a discipline problem. Without a written standard and tooling that checks it, every team makes reasonable but different choices, and the differences add up to a surface that nobody can learn in one go.
We write the standard with your teams: resource naming, errors, pagination, versioning, authentication, idempotency and webhook delivery. Then we make it cheap to follow, with linting in the pipeline, a gateway that handles the cross-cutting concerns, and contract tests that catch breaking changes before release.
The developer portal closes the loop. Partners and internal teams find accurate, generated documentation, try calls in a sandbox and get keys without opening a ticket.
Scope
Included
- API standard: naming, errors, pagination, versioning, idempotency
- API gateway setup: authentication, rate limits, logging
- Contract tests in the delivery pipeline
- Specification-first workflow with OpenAPI or AsyncAPI
- Webhook delivery with retries and signatures
- Developer portal with generated documentation and a sandbox
- Inventory of existing APIs and their consumers
- Migration plan for the most-used existing APIs
Not included
- Rewriting every existing API at once
- Building partner-specific business features
- Commercial API pricing and monetisation
- Operating the gateway after handover
How the work runs
- Weeks 1 to 2Take inventory. Existing APIs, consumers, versions and failure history are mapped, and the integrations that cost the most are identified.
- Weeks 3 to 5Write the standard. The API standard is written with your teams and checked against the APIs you already have. Exceptions are recorded, not hidden.
- Weeks 6 to 10Build the platform. Gateway, contract tests, specification linting and the developer portal are set up, and the first APIs are brought onto them.
- Final weeksMove and hand over. The most-used APIs are moved behind the gateway, and your teams take over the standard and the tooling.
What you receive
Everything is set up in your accounts and your pipelines.
Who this service is not for
- Companies with one or two stable integrations. A full platform would cost more than it saves.
- Teams that want the standard written but not enforced. A document without tooling is ignored within a quarter.
- Projects that need one specific partner integration built this month. We can build it, but on the platform, not as another one-off.
Frequently asked questions
REST, GraphQL or events?
Each has its place. Most companies need REST or HTTP APIs for partners, events for internal flows and sometimes GraphQL for their own front ends. The standard covers the styles you actually use.
Do we need a commercial API gateway?
Not necessarily. Open-source gateways and the managed gateways of AWS, Azure and Google Cloud cover most needs. We choose based on your traffic, your team and your cloud.
What happens to existing APIs that break the standard?
They are listed with an owner and a plan. The most-used ones move first; low-traffic ones may stay as recorded exceptions until they are retired.
How do contract tests work across teams?
Consumers describe what they rely on, providers run those expectations in their own pipeline, and a change that would break a consumer fails before release.
Can partners test without touching production?
Yes. The developer portal includes a sandbox with realistic test data and separate keys.
Start with a short technical call
Thirty minutes. You show us two or three integrations that hurt, and we tell you what a shared standard would change.