Skip to content

Custom Business Software

Integration platforms: connect each system once

Every new connection between two tools seemed small at the time. Now there are seven, each with its own idea of what a customer is, and when the supplier changes a field, something breaks quietly for a week. An integration platform replaces the tangle with one layer: every system connects to it once, and the layer owns the translations, the retries and the alarms. We connect each system once and take over the translations, retries and alarms.
Talk through your connectionsSee what the layer owns ↓
7 connections · 7 copies of the mapping5 connections · 1 mapping6 connections · 1 mappingcustomer = clientcustomer = accountcustomer = leadcustomer = contactcustomer = bill-tointegration layermappings · state · retries · monitoringField-service toolAccountingCRMSupplier portalWebsite formsPayrollsupplier renamed unit_price → price1 mapping fixed · every flow still running

Seven connections and nobody watching

Point-to-point connections grow one at a time: a form into the CRM, the CRM into accounting, jobs into the supplier's portal. Each copies the same translations, handles failure in its own way, or not at all, and reports to nobody. When one breaks, the first sign is a customer who wasn't invoiced.

An integration platform is a layer in the middle that you own. Each system connects to it once. The layer translates between them, keeps track of work that spans several systems, retries what fails, and tells a person when something needs them.

Today, and with an integration platform

Today

  1. 01Each pair of tools has its own connector or script.
  2. 02The same customer is mapped differently in each.
  3. 03Failures are retried by some connectors and dropped by others.
  4. 04Breakages are found by the people affected.

A change in one tool breaks another silently, and adding a tool means connecting it to all the others.

With an integration platform

  1. 01Each tool connects once, to the layer.
  2. 02One mapping of a customer, a job and an invoice, used by every flow.
  3. 03Failures are retried by rule and reported when retries run out.
  4. 04A new tool is one connection, reusing the mappings.

One place to look, one place to fix, and nothing breaks without someone being told.

What the layer owns

Five responsibilities that used to be scattered across every connection.

  1. 01

    Mappings

    One translation per record

    What a customer, job or invoice is called in each system, kept in one place.

  2. 02

    State

    Work that spans systems

    An order that touches four systems knows which steps are done and which are next.

  3. 03

    Retries

    By rule, not by luck

    Each failure retried on a schedule, with the same request, so nothing happens twice.

  4. 04

    Rules

    Your business logic, once

    Which jobs create purchase orders, which invoices sync and when, written in one layer.

  5. 05

    Monitoring

    Someone is told

    When retries run out or a system changes shape, a person hears, with the failed record attached.

One parts order across four systems

PO-3318 · IGN-4 × 6 · for the warehouse

  1. Reorder point reached in the field-service tool

    IGN-4 below 6 in the warehouse

    done

  2. Purchase order created

    PO-3318

    done

  3. Sent to the supplier portal

    timed out; retried after 2 minutes

    retrying

  4. Supplier confirmed

    delivery Thursday

    done

  5. Delivery received and counted

    6 received

    done

  6. Cost posted to accounting

    against PO-3318

    done

Done across four systems, with every step and the one retry recorded on the order.

The parts it's built from

Each part is built and tested on its own, so you can start with one and add the rest.

  1. Receive

    Webhook Orchestration

    Events from each system, checked and stored.

  2. Map

    API Integration

    • the event
    • the mapping
    • the rules

    retries run out → a person is told, with the record

  3. Run

    Backend Architecture

    Work across systems keeps its state.

  4. Watch

    Internal Tools

    A screen for what's running, waiting and failed.

Underneath every stepAPI ServicesThe layer's own API, for the systems you build next.

What changes from one business to the next

SystemsWhich tools connect, and which owns each record
MappingsHow a customer, job or invoice translates between them
RulesWhich events start which work
AlertsWho hears about which failures, and how

A common starting point is n8n or a small service with a job queue, a Postgres database for state and mappings, and each tool's own API. These are starting candidates, not requirements.

Is an integration platform the right system?

Good fit

  • Four or more systems pass the same records between them.
  • Failures are found by customers or at month end.
  • You expect to add or replace tools.

Avoid when

  • Two systems need one connection. A direct API integration is enough.
  • The real problem is two systems disagreeing about shared records. Look at cross-system sync.

How we'd approach it

Most of the early work is listing the systems, mapping what each calls a customer or order, and agreeing the rules and alerts.

  1. 01

    Understand

    As much as the problem needs

    We map how the work runs today: who does what, which systems hold the records, and where it breaks.

  2. 02

    Design

    Decided before it's built

    Ownership, rules, integrations and exceptions, agreed with you and written down with acceptance criteria.

  3. 03

    Build

    Connected to what you use

    We build the scoped system, connect it to the tools you already run, and test it on the cases that matter.

Related systems

The capabilities underneath

For your industry

Questions about integration platforms

Isn't this what our automation tool does?

Partly. Automation tools run flows. The platform adds what flows usually lack: shared mappings, state across systems, retries by rule and a view of what failed.

Do we have to rebuild every connection at once?

No. Connections move to the layer one at a time, starting with the ones that break most.

What happens when a tool changes its API?

The layer notices the change, flags the mappings affected and holds the work until it's fixed, instead of losing it.

Who watches it?

Alerts go to the person you name, with the failed record attached. You can also see everything that's running, waiting or failed on one screen.

Replace the tangle with one layer

Tell us which tools are connected today and which connections break. We'll show you what one layer would look like.

Start a project