Your systems already have the data. They just don't talk.

Every one gets scoped on its own. What it comes to depends on which systems are involved, how many kinds of record move between them, and what's supposed to happen when the two sides disagree. After a strategy call you get a written scope naming every flow and what it costs.

Usually not. Depending on the system there's scheduled file import and export, direct database access where the vendor permits it, email parsing, and automating the same screens a person would use as a last resort. Every one of those is more fragile than a real API. We say so plainly in the scope, along with what happens when it breaks.

The failed work is kept. Calls retry on their own with increasing delays, anything that still fails lands in a queue with the original data attached, and a person gets an alert. Once the cause is fixed, the queue replays. And the reconciliation report catches what the alerting doesn't, because a silent failure still shows up there as a mismatch a person can see.

Yes, as the first step of rebuilding it in your name and on your accounts, not as ongoing support for what's there. We start by reading what's actually in place, which with modern AI tooling is fast even in a codebase we've never seen, and two things get looked at first. Error handling, and how the credentials are stored, because that's where inherited integrations usually turn out to be fragile. Then we scope the replacement. If all you want is somebody to keep the old one running as it is, that's a job for whoever built it or your own IT, and we'll say so.

Not necessarily. For light workflows those tools are often the right answer, and the systems we build run real Make scenarios inside them today. Anything carrying money or inventory, we usually build the integration direct. You own it, there's no per-task fee that climbs with your volume, and the error handling can be made as serious as the data deserves.

Trust, and then time. The money losses are real (a duplicate invoice, an oversold item, a fee posted to the wrong account) but the expensive part is what comes after. Once two systems have disagreed in public, nobody believes either of them until somebody proves it again by hand, and that reconciliation turns into a permanent monthly job. It's why every integration we build ships with a reconciliation report a bookkeeper can read, rather than a log only a developer can.

No. Integrations connect through OAuth or an API key you generate in your own account, and both live in a secrets vault, never in the code and never in a document. You can revoke our access from your side at any moment without asking us. If somebody pastes a live secret into a chat message, our own tooling refuses it and tells the developer to get it regenerated. The tooling enforces that one, so it doesn't depend on anybody remembering.

One way wherever one way is enough. A two-way sync doubles the number of ways it can be wrong, so it has to earn itself. Two-way is right when people genuinely edit in both systems, say a customer record the office updates and the sales team updates. When it's right, the scope names which system wins a conflict, field by field, before anything gets built. The failure we find most often in inherited integrations is a one-way sync everybody gradually started treating as two-way.

It gets its own decision, written down. Backfilling history is a separate job from keeping things in step going forward, and it isn't always worth doing. Sometimes the right call is to start clean from a date, leave the old records where they sit, and put a note on the boundary so nobody wonders later. Where a backfill does earn its keep, it runs against a copy first and gets reconciled the same way live data does.

The integration keeps running until the old version is actually retired. Every serious API is versioned, and vendors deprecate on published schedules with plenty of notice. Under a support plan we track those notices for the systems you run and move you before the cutoff. If you're not on one, the monitoring still fires when calls start failing, so you hear it before your bookkeeper does and nothing breaks silently. None of it locks you to us either. The code is in your repository.