One way feeds
Data moves from one system to another, on a schedule or on an event.
System integration
Getting the programs you already pay for to work together
I connect the systems you already run, so the same information stops being typed into two of them, and the two stop disagreeing about which version is right.
Online shopREST
ERPSOAP
AccountingREST
Delivery companyREST
Payments providerHOOK
One versionthe same answer, wherever you look
Priced per projectset once we see what your systems allow
Built to be swappeda provider can change without a rewrite
Recognise this
You need this if
- The same data is entered twice, in two systems, by two people.
- Someone exports from one program and imports into another, by hand.
- Two systems disagree and nobody knows which one is right.
- A tool you pay for is barely used, because nothing reaches it.
- You find out something never arrived when a client asks about it.
Kinds of connection
Six ways data can move between systems
Which one is right depends on what your systems allow and on who is meant to change what. That is decided before anything is built, not after.
Two way sync
Both sides can change, and a rule decides which one wins.
Live lookups
A value is checked against the other system at the moment it is typed.
Bulk imports
History moved once, cleaned up, without anyone retyping it.
Event callbacks
The other system tells us the moment something happens, instead of us asking.
Exports
Your data leaves in a format another system, or another developer, can read.
GET/orderslist what came in
POST/orderscreate one
PUT/stock/{sku}update a stock level
POST/invoicesissue a document
GET/deliveries/{id}where the parcel is
POST/hooks/statusthe other side tells us
Example only. What a connection exposes depends on the systems involved.
One source of truth
When two systems hold the same fact, one of them decides
Most integration problems are not technical. They start when nobody said which system is right about a client address, a price or a stock level, and both keep changing it.
- For every shared fact, one system is the source and the others follow
- Conflicts are settled by a rule you agreed, not by whoever saved last
- The rule is written down, in words, before anything is built
- Where a fact must be editable in two places, that is a decision, not an accident
Shared factDecided by
Client detailsSource
Prices and termsSource
Stock levelsFollows
Order statusFollows
Invoice numbersRead only
Checked at entry
Wrong data is caught while it is typed, not months later
A code, a registration number, a customer reference: each can be checked against the system that owns it at the moment somebody types it, instead of turning out to be wrong when an invoice bounces back.
- Checked while typing, against the system that owns the answer
- A clear message when it does not match, in words, not a code
- Nothing saved half correct, waiting to be found later
- If the check cannot run, the person is told, not silently allowed through
A value, checked
Typedby a person
Checkedagainst the owner
Acceptedor explained
Matched the registerAccepted
Did not matchExplained
Register unreachableFlagged
When the other side is down
Nothing is lost because someone else had an outage
The systems you connect to will be unavailable sometimes. That is normal. What is not normal is losing the work that was in flight, or finding out weeks later that a day of data never arrived.
- What cannot be delivered is held, in order, not dropped
- It is sent again when the other side is back, without anyone retyping
- A person is told if it stays down longer than agreed
- You can see what is waiting, and since when
What you can look at when something goes wrong
09:14:02INFO
09:14:02INFO
09:14:03INFO
09:15:11WARN
09:15:11INFO
09:15:41ERR
09:15:41INFO
09:23:07INFO
09:23:07INFO
09:23:08INFO
The same thing, twice
A message that arrives twice does not create two orders
Systems repeat themselves. A callback fires again, a retry succeeds after all, someone presses a button twice. Handled badly, this is how a client ends up with two invoices for one delivery.
- The same event, received twice, has the effect of one
- Every message carries an identity, so a repeat is recognised
- Signatures are verified, so only the real sender is believed
- The duplicate is recorded, not silently thrown away
The event, first time
{
"event_id": "evt_8f21c4",
"type": "order.confirmed",
"order_id": 4417,
"signature": "verified",
"applied": true
}
The same event, again
{
"event_id": "evt_8f21c4",
"applied": false,
"reason": "already applied",
"orders_created": 1
}
Leaving is possible
A connection you can move away from
Providers change: prices go up, a service closes, you find a better one. Each connection is built behind its own boundary, so replacing it is a piece of work, not a rewrite of how your business runs.
- Business rules live in your system, not inside the connection
- A provider can be replaced without touching the rest
- What is connected, and how, is written down
- Credentials are yours, in your accounts, from the first day
What stays yours
The connection
One provider, one boundary
Replaceable on its own
No business rules inside it
Documented, not remembered
Yours either way
The rules of your business
The data on both sides
The accounts and credentials
The source code
How it runs
From two systems that ignore each other to two that agree
See what is allowed
What each system exposes, what it refuses, and what access you actually have.
Agree the rules
Which side is right about what, and what happens when they disagree.
Build and test
Against the other side's test environment first, never straight onto live data. The connection itself runs through middleware I build, with its own security layers, on a VPS behind a VPN tunnel.
Watch, then leave it
It runs on real traffic while somebody is still looking, before it is trusted.
How much
What decides the price
Priced per projectset once we have seen what your systems allow. A connection that reads one value and a two way sync across three systems are not the same work.
Three things move ithow many systems are involved, whether they have a usable interface, and how much history has to be moved across at the start.
Questions
Frequently asked questions
Which systems can you connect?
In principle, any system that offers a way in: ERP, CRM, accounting and invoicing, couriers, payment providers like Stripe, email. Which of yours qualify is one of the first things we find out, because it decides both what is possible and what it costs.
What if my system has no way in?
Then we look at what else it offers: a scheduled export, a database we are allowed to read, a file it can drop somewhere. If none of that exists either, I will say so instead of building something fragile that breaks the first time the other side changes a screen.
How much does it cost?
It is priced per project, once we have seen what your systems allow. Three things move the figure: how many systems are involved, whether they have a usable interface, and how much history has to be moved at the start. The first conversation costs nothing.
What if the data does not match today?
That is the normal starting point, and it is better to find out now than later. Part of the work is deciding what happens to the records that disagree: which version wins, what gets corrected, and what is left alone because it is history.
What happens when the other side is down?
What cannot be delivered is held in order and sent again when the other side is back. A person is told if the outage lasts longer than agreed. You can see what is waiting and since when, so nobody has to guess.
Who gets access to my systems, and on what terms?
An NDA is signed before I am given any access, not after it. That order is deliberate. Letting somebody into the systems your business runs on is the part clients think hardest about, and it belongs in writing before anything is connected.
Who owns the connection if I leave?
You do. The accounts and credentials are yours from the first day, the source code is yours, and how everything is connected is written down rather than kept in someone's head. Each connection sits behind its own boundary, so another developer can replace one without touching the rest.
Which two systems should stop disagreeing?
The first step is finding out what they will let us do.