When you need it
Your product depends on outside APIs, and each integration was built a different way. When a partner is slow or sends the same message twice, orders fail or are duplicated, and nobody can see why.
What sets the quote
- 2 weeks: one external system, with up to 10 endpoints and one authentication method.
- 8 weeks: up to 5 external systems, with up to 40 endpoints and 3 authentication methods, such as API keys, OAuth 2.0 client credentials, signed webhooks or mutual TLS.
- Endpoints count both the partner APIs you call and the APIs and webhooks you publish.
- Both sizes assume up to 1 million requests or messages a day and payloads under 1 MB. Higher volumes, bulk files or batch transfers add load testing to the quote.
- Larger scopes are quoted after sizing from your list of systems, endpoints and volumes.
What changes
- Every supplier and partner connects through the same tested pattern, so the next integration is quicker to add.
- A slow or failing partner is cut off by timeouts and a circuit breaker instead of stalling the rest of your product.
- Duplicate messages and retried webhooks do no harm, because each change is applied only once.
- Every request and response can be traced, so support questions get a clear answer.
What you get
- Integration architecture with a standard pattern for adding new systems
- Connectors for the agreed endpoints, with timeouts, retries with backoff and circuit breakers
- Idempotent processing, and webhook handling with signature checks
- Queues with dead-letter handling on your cloud's managed service: Amazon SQS, Azure Service Bus or Google Cloud Pub/Sub
- Partner credentials in AWS Secrets Manager, Azure Key Vault or Google Cloud Secret Manager, never in code
- An archive of raw requests and responses for tracing and replay, kept for the period you set
- Monitoring and alerts per integration for errors, latency and queue depth
- Contract and failure tests in CI/CD, and documentation for your team
Choose this package when your product already exists and its integrations are the weak point. For a new product, integrations are part of the cloud-native web app. We built the payments for our own B2B and B2C travel commerce platform. After go-live, application support keeps connectors current when partners change their APIs.
Not included
- Changes inside your partners' systems
- Licensing or roll-out of an integration product, such as MuleSoft or Boomi
- Migration of historical data
- Penetration testing (we can refer you to a certified partner)
- Running the integrations after go-live (available as application support, with optional 24/7 on-call)
What we need from you
- API documentation and sandbox access for each external system, which you request from the partner.
- Example payloads and expected volumes, including peak hours.
- A technical contact on your side, about two hours a week, for questions about data and errors.
- A repository in your GitHub, GitLab or Azure DevOps organisation.
- Build access in the target environments: AWS AdministratorAccess through IAM Identity Center, Azure Contributor with Role Based Access Control Administrator, or the Google Cloud Owner role.
How it works
Free 30-minute call, then your list of systems, endpoints and volumes, and a written fixed quote.
A senior architect maps each system's limits, authentication and failure modes, and agrees the integration pattern with you.
The first connector is built end to end; the rest follow in short iterations, each reviewed as a pull request. Vetted specialists join when the scope needs them.
Failure cases such as timeouts, rate limits and duplicate webhooks are tested before go-live.
Go-live with monitoring in place, then handover and a walkthrough with your team.
At a glance
- Duration
- 2–8 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and developers
Related services
Product and architecture discovery
A discovery of 1–2 weeks that turns a product idea into a first-release scope, an architecture, a build estimate and a delivery plan, before you commit budget to the build.
Cloud-native web app or MVP
A web app or MVP with its API, built in your own AWS, Azure or Google Cloud environment in 4 to 12 weeks, with infrastructure as code, CI/CD and security gates from the first commit.
Legacy app modernisation
Older applications, including .NET and IIS apps, moved into containers on Amazon ECS on AWS Fargate, Azure Container Apps or Cloud Run, with CI/CD and a tested rollback for every release.