Calango LabA record of every exchange
Every message in and out is stored. When someone asks "did that order come through?", the answer is a log, not a guess.
06 Data getting across
Two systems. One conversation.
For when data has to cross from one system to another and today it crosses through a person exporting, checking and retyping. It’s invisible work that costs hours, creates errors and disappears the week that person takes leave.
Data crossing on its own
Integration isn’t connecting two logos. It’s settling what happens when orders arrive out of sequence, when the far end is slow to answer, and when the same record comes back twice — which is exactly where improvised integrations break.
What crosses
Ordersfrom cart to ERP, with items, price and shippingStockdrawdown and restock, in both directionsInvoicesissued at checkout, with the number coming backCustomersaccounts and addresses with no retypingStatuspicking, dispatch and delivery reaching the customerPaymentsconfirmation, refunds and reconciliation
What holds it up
What keeps it from breaking quietly
This is the difference between an integration and a scheduled script — and it’s where the bill turns up months later, while nobody was watching.
Retries with growing backoff
Third-party APIs go down — that’s a fact of life, not an exception. The integration waits and tries again at longer intervals instead of losing the data on the first error.
Alerts when it keeps failing
A one-off failure resolves itself. A repeated one becomes a warning to an actual person, before the customer calls to complain.
Reprocessing without duplicates
Resending what failed can’t create two orders or two invoices. Every event carries its own identifier, and anything already through is recognized and ignored.
An integration nobody monitors isn’t working — it’s working until further notice, and you find out which of the two from the customer’s phone call.
Questions
What people usually ask
The system we use has no API. Is it still possible?
Almost always, by another route: scheduled file exports, a reachable database, spreadsheet imports, or a robot driving the interface when nothing else is left. The research says which route exists and what each one costs in reliability — and that part goes in writing into the proposal.
We already have a script that does this. Why replace it?
If it works and somebody understands how, don’t replace it. What’s usually missing is everything around it: a log of what went through, retries when the far end drops, alerts when it fails, and someone who knows how to touch it. A script without that works right up until the day it doesn’t — and nobody notices until the customer calls.
How long does an integration take?
Entirely down to the far end: a documented, stable API is one scenario, a closed system with no documentation is another. That’s why the first step is always research on both ends, and the timeline only becomes a commitment after it.