API development and integration services for products that depend on other systems

Two kinds of API work

Most requests we receive fall into one of two groups. The first is building an API: the interface your web app, mobile app, partners or customers call. The second is integration: making your product work with systems you do not control, such as a payment provider, a CRM, an advertising platform or a legacy database. The skills overlap, but the risks differ. Your own API fails when it is badly designed. An integration fails when the other side changes, slows down or sends the same event twice, and your code was not written to expect it.

What we build

How we make integrations reliable

• Idempotent writes. Every operation that creates or charges something carries an idempotency key, so a retry after a timeout cannot create a second order or a second charge.
• Verified, queued webhooks. We check the signature, store the raw event, acknowledge quickly and process from a queue. Duplicate and out-of-order events are expected and handled.
• Retries with limits. Failed calls retry with backoff, then move to a dead-letter queue where a person can see and replay them. Nothing fails silently.
• Respect for rate limits. Sync jobs run with controlled concurrency and resume where they stopped, so a large account does not exhaust a provider's quota.
• Reconciliation. For payments and CRM data we keep our own record and compare it with the provider on a schedule, because webhooks alone will eventually miss something.
• Contract tests and monitoring. Tests run against provider sandboxes in CI, and dashboards show failure rate and lag for each integration.

Integration work we have shipped

• TamTracker: nine integrations including LinkedIn Ads, HubSpot, Google Ads, Zoho CRM and ActiveCampaign, using OAuth, API-key and webhook authentication. Syncs run through an SQS queue and an ECS Fargate task with a dead-letter queue, three retries and one-at-a-time concurrency to respect provider limits.
• Paint Nite: a six-stage checkout with idempotent Stripe payments and an atomic order transaction, with separate Stripe accounts, keys and webhook secrets for the US and Canada.
• Seek My Service: a NestJS API with more than 80 REST endpoints documented in Swagger, Stripe payments for vendor credits, and notifications through Twilio SMS and SendGrid email.
• Edge OCR: four Stripe subscription plans with usage limits, overage purchases and full webhook handling.

API design principles we follow

1. Write the contract first. An OpenAPI or GraphQL schema is reviewed before code, so front-end and partner teams can start against a mock.
2. Authorise every object. Each request checks that the caller may access that specific record, which addresses the top risk in the OWASP API Security list.
3. Version from the first release. Breaking changes go into a new version with a published deprecation date.
4. Return errors a developer can act on: a stable code, a human message and a request ID that matches your logs.
5. Paginate, filter and limit by default, so one request cannot pull the whole table.
6. Document as part of the work. Reference docs and examples are generated from the contract and shipped with the API.

What it costs

Effort depends mostly on the other system: the quality of its API and sandbox, its rate limits, and how many edge cases your business rules add. We read the provider's documentation and test the sandbox before we estimate.

How a project runs

1. Discovery: the systems involved, the data that moves between them, which side is the source of truth and what must happen when a call fails.
2. Contract and spike: the API schema or integration design, plus a working call against each provider sandbox to surface surprises early.
3. Build in sprints, with contract tests and a staging environment connected to sandbox accounts.
4. Hardening: failure injection, load tests against rate limits, reconciliation jobs and alerting.
5. Handover: reference docs, runbooks for the failure cases and dashboards your team can read.