Your systems already talk. Badly.
A nightly CSV. A spreadsheet somebody emails on Fridays. A script a contractor wrote in 2019 that nobody has opened since.
It holds until a vendor ships an update, and then a week disappears into finding out which of the four things broke. We replace that with something you can monitor and change.
Email usBoring integrations are the good kind
The failure modes are well known and the fixes aren't clever. Retries that don't duplicate records. Idempotent writes, so replaying yesterday's file is safe. Schema checks at the boundary, so a renamed column stops the load instead of silently emptying a field.
Then someone gets told when it breaks. An integration with no alerting is a scheduled outage you haven't been informed of yet.
-
Every run leaves a record: what it read, what it wrote, what it skipped and why.
-
Reprocessing a day is one documented command, not an archaeology project.
-
Credentials live in a secret store with rotation, not a config file on a server somebody set up in 2020.
Patterns we use
Which one fits depends on what your systems will let you do, not on what's fashionable this year.
Still correct for nightly finance and record loads. Cheap, predictable, and easy for your team to operate.
Where the delay matters. A signup provisions access in seconds rather than overnight.
A stable interface in front of a vendor system, so a change on their side is one fix rather than fifteen.
Single sign on, provisioning and deprovisioning, so someone who leaves in March loses access in March.
Before we build, we try not to
A surprising share of integration requests get answered by a setting in a product you already pay for, or by two teams agreeing on a file format. We check that first, at our expense, because building the wrong connector is expensive for both of us.
When a build is the answer, we scope it to the smallest thing that removes the manual step, and then stop.
The awkward questions
Integration work fails in predictable places.
-
Our vendor won't give us API access.
Common, and it changes the design rather than ending it. Database replicas, secure file exchange and scheduled exports all work.
Worth asking the vendor once more with a specific use case attached. The answer is often different when you aren't asking in general terms.
-
Who runs it after handover?
Your team with our documentation, or us on a support arrangement. Both are fine. What we won't do is leave you something only we can operate.
-
How do you test against a live system?
Against your test tenant where one exists. Where it doesn't, we build recorded fixtures from real payloads with identifying fields removed, and agree a rollback before anything writes to production.