Skip to main content
Fugen Services logo

Software Engineering

Getting your systems to talk to each other, reliably

Most integration work fails on the unhappy path. The demo works, the happy case works, and then the payment provider times out mid-request, or the accounting API rate-limits you at month end, and nobody knows whether the order was created twice or not at all. Handling that properly is the actual job.

Indicative

Integration from £4,500; full API from £12,000

Fixed price agreed in writing before any build starts.

Get a quote+44 7488 265083

The problem this solves

Two patterns cause most integration pain. Calling a third-party API synchronously inside a web request, so their slow day becomes your outage. And no idempotency, so a retry creates a duplicate order, a duplicate invoice, or a duplicate charge — and reconciling that manually costs more than building it correctly would have.

What you get

Designed before it is built

Resources, verbs, status codes, error shapes, pagination and versioning agreed up front as an OpenAPI specification. Changing a published API is expensive; changing a document is not.

Authentication that fits the consumer

OAuth 2.0 where third parties act on a user’s behalf, signed keys for server-to-server, short-lived tokens with refresh for mobile clients. Chosen to match who is calling rather than by habit.

Idempotency and retries

Write operations accept an idempotency key so a retried request cannot create a second record. Outbound calls use exponential backoff with a circuit breaker, so a failing dependency degrades rather than cascades.

Webhooks that can be trusted

Signed payloads, replay protection, and a delivery log with manual redelivery. On the receiving side, verify then queue — never process a webhook synchronously inside the request.

Rate limiting and quotas

Per-consumer limits with clear headers and 429s, so one client cannot degrade the service for everyone else. This is what makes an API safe to give to a partner.

Documentation that stays true

Generated from the specification and published with real request and response examples, so it cannot drift from the implementation the way hand-written docs always do.

How we work

  1. Map the flow

    What data moves, in which direction, how often, and what must happen when a step fails. The failure question is the one that shapes the design.

  2. Specify

    OpenAPI document reviewed with whoever will consume it, before code exists. Consumers find design problems that producers cannot see.

  3. Build against a contract

    Implementation plus contract tests, so a breaking change fails CI rather than a partner’s integration.

  4. Harden the edges

    Timeouts, retries, circuit breakers, dead-letter queues and structured logging.

  5. Sandbox and go live

    A sandbox environment with test credentials for consumers to build against, then a staged production release.

  6. Monitor

    Error rate, latency and failure counts per integration, alerting when a dependency starts to fail rather than after it has.

What you should expect

  • A third-party outage degrades one feature instead of the whole site
  • Retries cannot create duplicate orders, invoices or charges
  • Partners integrate from the documentation without asking your team
  • Breaking changes caught by contract tests, not by a partner

Built with

  • Node.js
  • TypeScript
  • Laravel
  • PHP
  • Python
  • FastAPI
  • OpenAPI
  • GraphQL
  • REST
  • PostgreSQL
  • MySQL
  • Redis
  • RabbitMQ
  • Stripe
  • Xero
  • QuickBooks
  • Shopify
  • Twilio
  • SendGrid

Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.

API Development & Integration — your questions

Including the ones about cost, which most agencies leave off the page.

A single well-scoped integration — one payment provider, or a CRM sync — typically runs £4,500 to £9,000. A full API for external consumers, with authentication, rate limiting, sandbox and documentation, starts from £12,000. The variable is almost always how well the other system behaves.

REST for most things, and GraphQL when a client genuinely needs to compose its own queries across related data — typically a mobile app trying to reduce round trips. GraphQL adds real complexity in caching, rate limiting and query-cost control, so it needs a reason beyond preference.

Often, though we will be clear about the trade-offs. Options are a database-level integration where we can reach it, scheduled file exchange, or as a last resort screen scraping — which works but breaks whenever the other side changes their markup. We price scraping as ongoing maintenance rather than a one-off, because that is what it is.

That is designed for from the start. Outbound calls run through a queue with retries and a circuit breaker, so a failing provider means a delayed action rather than a failed request or a 500 page. Anything unrecoverable lands in a dead-letter queue with an alert, so nothing is silently dropped.

Yes, generated from the OpenAPI specification so it cannot go stale, published with working examples and a sandbox to try against. Hand-written API documentation is out of date within two releases, which is why we do not write it that way.

Versioned in the URL path, with a written deprecation policy — additive changes go into the current version, breaking changes get a new one, and the old version stays available for an agreed window. Consumers plan around it instead of discovering it.

Talk to someone who has built this before

A short call is usually enough to tell you whether this is the right service for your situation — including when it is not.