All expertise

04

Integrations

Make the systems you already own talk to each other, without rebuilding them

An integration doesn't fail when the vendor answers "error". It fails when it answers "fine" and does nothing, or when it sends the same order twice. That is where we start.

How we connect two systems
  1. InventoryWhat each system exposes and — above all — what it does not
  2. ContractData schema and error cases agreed before any code is written
  3. BridgeThe translation between the two models lives in one place, not scattered
  4. RepeatabilityEvery operation can be redone without harm: sooner or later it will be
  5. Safety netA periodic check realigns state when the other side goes quiet
  6. AlertingIf the link breaks we find out, not your customer

The contract comes first

Every exchange declares a schema: what comes in is checked before it touches anything, what goes out is documented. The payoff shows up on integration day: instead of discovering fields by trial and error, there is a document stating what arrives and what comes back — and a test that fails when someone changes it.

Duplicates, retries and a safety net

Messages arrive twice, out of order, or never. Every state-changing operation is written so it can be repeated without harm, and every queue has a retry ceiling with growing backoff.

When a vendor's connection proves unreliable you don't beg it: you put a periodic check beside it that realigns state. It costs little and removes a whole class of phone calls.

Systems that don't want to talk

Business systems with interfaces from the 2000s, platforms exposing a slice of what you need, public administration portals that accept a file and nothing else: the work is a layer that normalises all of it into one model, and keeps each vendor's quirks in a single place.

Portfolio

What we did on this, project by project.

Manora

API of a blockchain platform

  • Documented APIs with input validation, rate limits and metrics exposed for monitoring.
  • A separate process follows the chain block by block, rebuilds transactions and balances in PostgreSQL and resumes from where it stopped.
  • Multilingual notifications to the app, generated from chain events rather than from the write path.
  • Node.js
  • PostgreSQL
  • Redis
  • OpenAPI
  • Prometheus

BigFishIta

Public APIs and LinkedIn integration

  • Read-only APIs for content and company profile with a per-company key: external automations read without the database being opened.
  • Integration with the social publishing platform: inbound messages handled across the two payload shapes the vendor alternates, plus a five-minute check that realigns status and comments when the connection goes quiet.
  • A job queue in PostgreSQL with exclusive claims and retries, drained on a schedule and right after each insert.
  • Next.js
  • PostgreSQL
  • webhooks
  • cron

CocoonServer

Management console for Odoo instances

  • Every route behind a single typed authorisation check: authentication is never rewritten by hand per endpoint, so it cannot be forgotten.
  • Long operations streamed to the browser as they happen, instead of a request that times out in silence.
  • Next.js
  • Prisma
  • Kubernetes API
  • SSE

Need this?

Tell us the problem and we'll tell you how we would tackle it — and if it isn't worth doing, we'll tell you that too.

Let's talk