9 pointers on software integrations that hold up

Software integrations are the part of your software estate that nobody owns. Each one was set up by whoever needed it, in a hurry, to solve a problem that has since been forgotten. They work invisibly until they stop, and when they stop, the first sign is usually a colleague noticing that a number looks wrong.

That is the actual risk in this category, not that integrations are hard to build, but that they are easy to build and nearly impossible to keep track of. This page is about evaluating them honestly and running them without accumulating a debt you cannot see.

What to take away

Four kinds, with different economics

"Integration" covers four quite different arrangements. Knowing which one you are buying changes what you should ask.

Native connections, built by one vendor into another's product. The products most businesses already run — Salesforce, HubSpot, NetSuite, QuickBooks, Google Workspace, Microsoft 365, Slack — publish native connections to at least some of the others, and each of them also exposes an interface for connections you build yourself. Native is the cheapest to set up, the least flexible, and entirely dependent on both vendors continuing to care. They break when either side ships a change, and you have no influence over the repair.

Integration platforms, which sit between systems and are configured rather than coded: Zapier and Make at the small end, Workato, Tray.io, Boomi, MuleSoft and Celigo further up, and n8n if you would rather host it yourself. They are fast to build and visible, and they introduce a third vendor, a third bill, and a third thing that can fail. Pricing is usually metered on volume, which means a busy month costs more than a quiet one: model your peak, not your average.

Direct connections you build, using each system's interface. Maximum control, and you own the maintenance for ever. The real cost is not building it; it is being the organization that must react when a vendor changes something.

File exchange: a scheduled export from one system, imported by another. Unfashionable, reliable, easy to debug, and perfectly adequate for anything that does not need to be immediate. Frequently the right answer for reporting and finance, and frequently dismissed for being unexciting.

Match the mechanism to the requirement. Most work does not need to happen within seconds, and choosing a real-time mechanism for work that could run overnight buys you complexity you will maintain for years.

What "integrates with" actually means

The word on the marketing page carries almost no information. When a vendor says they integrate with something you use, ask:

Ask these about the two or three integrations you actually depend on. The catalog size is irrelevant; a vendor with a thousand connectors and a poor one for your accounting system is worse for you than one with fifty good ones.

Whose identity is the connection using?

This is the question that causes the most avoidable breakage, and almost nobody asks it during an evaluation.

When you connect two systems, the connection authenticates as somebody. Usually that somebody is the person who clicked "authorize", which means the integration inherits their access, and dies when their account does. The pattern is familiar: an automation stops working weeks after someone leaves, and it takes days to work out why, because nobody connected the departure to the failure.

What to do instead:

Scoping gets skipped because everything works either way on day one. The questions a default configuration glosses over are authentication and authorization: which identity the connection runs as, what scopes it was granted, and who can change them. A SOC 2 Type II report tells you how a vendor manages access to its own systems, but it will not tell you what your connection was granted.

The useful habit is to grant a connection the narrowest access that lets it work.

Then include integrations in your offboarding checklist. "Which automations run as this person's account?" belongs beside "what happens to their mail".

Five ways integrations fail

They rarely fail loudly. Learn the shapes:

The common thread is that four of these five are invisible without deliberate monitoring. The most valuable thing you can build around any integration is an alert that fires when the expected thing does not happen: a daily transfer that did not run, a queue that did not drain. Error alerting only catches the failures that announce themselves. That is what a dead-man's-switch service does — Healthchecks.io and Cronitor watch a scheduled job and alert you when the expected ping never arrives — and PagerDuty, or whatever already carries your on-call pages, can deliver the alert to a person.

Limits, versions, and the slow deprecation

Three constraints that shape what is possible:

Rate limits. Every interface caps how much you may do in a period. This is fine day-to-day and becomes the binding constraint during bulk operations, an initial load, a mass update, a migration. Find the published limits before you plan anything bulk, and find out what happens when you exceed them: a clear refusal you can retry, or a temporary block on the whole account. A refusal is a normal, documented response rather than a fault: HTTP 429 (Too Many Requests) is the standard reply, and the Retry-After header it carries tells you how long to wait. Being able to describe that too many requests reply and the retry hint it carries is enough to hold the conversation with whoever built the thing.

Versioning. Interfaces change. Well-run vendors version them, announce deprecations, and give you a window. Others change behavior without notice. Ask how changes are communicated, where they are published, and how long old versions are supported, and then make sure the announcement reaches a mailbox someone reads, not the address of whoever set the connection up.

Bulk versus incremental. Most systems offer a fast path for large volumes and a normal path for ongoing changes. Using the wrong one is why an integration that worked in testing hits limits in production.

What to test before committing

Keep a register

The cheapest useful thing in this category is a single list, kept somewhere permanent, with one row per integration:

what it connects, which direction, what it is for, who owns it, which identity it authenticates as, where the credentials live, how it is monitored, and what happens if it stops for a week.

That last column is the one that pays. It tells you which integrations deserve monitoring and which can simply be fixed when someone notices. Without it, everything is treated as equally critical, which in practice means nothing is monitored at all.

Review the register when you change either system, when someone leaves, and on a schedule. It is also the document that makes a future migration tractable, because the alternative is discovering your integrations one outage at a time.

What makes this expensive to leave

Integrations are the reason platform migrations overrun. Every connection is a small separate project with its own owner, its own credentials, and its own testing. Ten integrations is not one task, it is ten, and they cannot be done by one person in parallel because each needs the cooperation of whoever owns the system at the other end.

The mitigating actions are cheap and must all happen early. Keep the register. Prefer file exchange when immediacy is not required.

Use function accounts, not personal ones. Avoid deep dependencies on a connector only one vendor maintains.

Where to read next

Connections exist because work spreads across products, so product decisions shape how much connecting you need. Choosing a project management tool often removes the need for two or three connections on its own.

The team collaboration decision sets how many notification feeds you build. The file sharing and storage decision sets whether documents need copying between systems. The account administration decision sets where identities and credentials for connections are managed.

Common questions

Should we build connections ourselves or buy a platform?

Count how many you need and how often they change. Few and stable favors native connectors or a scheduled file. Many and changing favors a platform. Building from scratch is right when one connection matters enormously and nothing off the shelf fits.

How do we find the connections we already have?

From several directions at once: each product's connected applications list, non-human accounts, the finance record for small recurring charges, and a short message to every team.

Ask every team what would break if this product stopped for a day. The last one finds the most.

What is a reasonable review interval for the register?

Twice a year, plus whenever somebody leaves. The review has two jobs: confirm every connection still has an owner, and switch off the ones nobody can justify. The second job is where the value is.

Is real time worth the extra complexity?

Only where a person is waiting for the result. Immediate delivery multiplies the failure modes and the cost, and a great deal of what gets specified as instant is read at the next weekly meeting.