AI integration software: the connector layer and what breaks it

Integration looks like the easy part — two systems, an API each, some fields mapped between them. It is the layer that breaks most often, and almost always for the same three reasons: a credential expired, a schema changed, or a limit was hit.

None of those are interesting problems and all of them are the difference between an integration that runs for years and one that needs attention every few weeks. What a connector does about them is what you are actually buying when you buy integration software.

What we'll cover

• Why integrations break
• Authentication is most of it
• Schema drift
• Building it with CodeWords
• Rate limits and backpressure
• Mapping data between systems
• When no connector exists
• Monitoring the integration layer
• Deciding the direction of data
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why integrations break

Credentials expire or are revoked, which is the most common single cause.

Schemas change — a field added, removed, renamed or retyped — usually without notice.

Limits are hit, at volume, in bursts, or because something retried aggressively.

The other system has an outage, which is normal and should be survivable rather than exceptional.

Semantics change without the schema changing, which is the hardest case: the field is still there and now means something slightly different.

Almost none of these produce a clear error, which is why the failure is usually discovered late.

Authentication is most of it

Token refresh is where integrations die. A refresh token that expires, or a refresh flow that fails silently, stops everything.

Scopes matter. An integration granted broad access is a risk; one granted too little fails on an operation nobody tested.

Personal connections are the trap. A connection authorised by an individual breaks when they leave and grants their access until then.

Service accounts are the answer where the platform supports them, which not all do.

Revocation happens — a security review, a password change, an administrator tidying up — and the integration should say so rather than going quiet.

Alert on credential expiry ahead of time, since this is entirely predictable and is still the most common cause of an outage in this layer.

Schema drift

Additive changes are usually safe, provided your parsing ignores unknown fields rather than rejecting them.

Removals and renames break things, and they happen with varying amounts of notice.

Type changes are the nastiest — a number becoming a string, a field becoming nullable — because they frequently pass validation and produce wrong behaviour.

Validate what you receive, rather than assuming the contract holds, which is the practice that turns a silent corruption into a visible failure.

Pin the API version where the provider offers versioning, and treat an upgrade as a change requiring testing.

Watch for the empty result that used to be populated, which is the signature of a quiet schema change.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the systems, the data, and what should happen when one is unavailable.
3. Authorize the connections, scoped to what the automation needs.
4. Describe the exceptions: an expired credential, a rate limit, an unexpected response shape, a timeout.
5. Run it against real data and check the behaviour when you deliberately revoke a credential.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Rate limits and backpressure

Limits differ per endpoint, not just per service, which surprises people building bulk operations.

Respect the headers where they are provided, rather than discovering the limit by hitting it.

Back off exponentially with jitter, since synchronised retries make a limit problem worse.

Never retry unboundedly, which converts a transient problem into a sustained one.

Queue rather than drop, so a limit produces delay rather than data loss.

Watch your own concurrency, because a fan-out pattern is the fastest way to exhaust a quota that was comfortable sequentially.

Mapping data between systems

Identifiers are the hard part. Two systems rarely agree on what identifies a record, and the matching logic is where most integration bugs live.

Keep a mapping table rather than deriving the correspondence each time, which is both faster and debuggable.

Handle the unmatched explicitly, as a visible queue rather than a silent skip.

Units, currencies and timezones must be stated rather than assumed, and mismatches here produce errors nobody notices for months.

Enumerations rarely correspond, so a status in one system maps to a status in another by a decision somebody made and should have written down.

Do not copy what can be referenced, since every copied field is one that can diverge.

When no connector exists

Check for an API first, and whether it covers the operations you need rather than only reading.

A scheduled export or import is a legitimate integration and is the pragmatic answer for many older systems.

Email and file drops are still how a lot of business data moves, and treating that as a real integration pattern is more productive than refusing to.

Screen scraping is a last resort with real fragility and frequently terms-of-service implications.

Ask the vendor, since an undocumented API sometimes exists and is sometimes supported on request.

Count the maintenance of a custom connector honestly, because it is yours forever once you build it.

Monitoring the integration layer

Alert on credential expiry before it happens, which is the highest-return alert in this whole subject.

Watch error rates per integration, not in aggregate, since one failing connection is invisible in a total.

Watch for absence. An integration that stops receiving data looks identical to a quiet period.

Track latency, since a slowing dependency is an early warning of something.

Record the payloads for failed calls, which is what makes an investigation possible rather than speculative.

Report per connection: last success, error rate, credential expiry date.

Deciding the direction of data

Before any connector question, there is a design decision that determines how much integration work exists at all: which system owns each piece of information.

One owner per field, with everything else reading rather than storing, removes most of the synchronisation problem by removing the need for it.

Display instead of copy wherever the consuming system allows it, since a value that is fetched cannot drift.

One-way beats two-way by a wide margin, because bidirectional sync has no natural conflict resolution and forms loops.

Write the ownership map down, field by field, since this is the artefact that prevents the arguments a year later.

Revisit it when adding a system, because every new tool wants to own something and will by default.

Most integration complexity is self-inflicted, created by copying data that did not need copying.

Making it survive

Make every write idempotent, since retries are the normal recovery and duplicates are the usual cost of getting this wrong.

Persist before processing, so a downstream failure delays rather than discards.

Degrade rather than fail where the integration is not critical to the immediate outcome.

Keep credentials scoped and rotatable, and know how long rotation takes before you need to do it urgently.

Report the outcome: calls made, failures by type, retries, and connections approaching expiry.

Limits worth knowing about

You inherit the other system's reliability, entirely.

Rate limits cannot be engineered away, only accommodated.

Vendor API changes are outside your control and notice periods vary from generous to none.

Sandbox environments differ from production in ways that hide problems until go-live.

No integration layer fixes disagreeing data models, which is a decision about which system owns what.

What to build first

Credential expiry alerting across every connection you have, with the expiry date reported before it matters. It is the most common cause of integration failure, it is entirely predictable, and it is the one class of outage in this layer that is fully preventable with a calendar and a check.

Two habits make the difference. Use service credentials rather than personal connections, since an integration authorised by an individual breaks when they leave and holds their access until then. And validate the shape of what you receive rather than trusting the contract, because a schema change that passes unvalidated produces wrong behaviour instead of a clean failure and is discovered months later.

Frequently asked questions

Why do integrations break?

Expired or revoked credentials, schema changes, rate limits, outages in the other system, and semantic changes where a field still exists but means something different. Almost none of these produce a clear error.

What is the single most common cause?

Credentials. Token refresh failing silently, a refresh token expiring, or a connection being revoked during a security review — all of which are predictable and still account for most outages in this layer.

Why avoid personal connections?

Because they break when the person leaves and grant that person's access until they do. Service credentials scoped to what the automation needs are the answer wherever the platform supports them.

What kind of schema change is worst?

Type changes — a number becoming a string, a field becoming nullable — because they frequently pass validation and produce wrong behaviour rather than a clean failure.

How should rate limits be handled?

Respect the headers where provided, back off exponentially with jitter since synchronised retries worsen the problem, queue rather than drop, and watch your own concurrency — fan-out exhausts quotas that were comfortable sequentially.

What is the hardest part of mapping data?

Identifiers. Two systems rarely agree on what identifies a record, which is where most integration bugs live. Keep a mapping table rather than deriving the correspondence each time, and surface unmatched records rather than skipping them.

What if no connector exists?

Check for an API covering the operations you need, then consider scheduled export or import, which is a legitimate pattern for older systems. Screen scraping is a last resort with real fragility and frequent terms implications.

What is the most valuable alert in this layer?

Credential expiry, raised before it happens. It is the most common failure and the only one that is entirely preventable.

How do I reduce integration work overall?

Decide which system owns each field and have everything else read rather than store it. Most integration complexity is self-inflicted, created by copying data that did not need to be copied.

Is bidirectional sync ever the right answer?

Rarely. It has no natural conflict resolution, forms loops easily, and diverges on exactly the records where matching failed. One-way, with one owner per field, is simpler and covers most real requirements.

Related reading

• AI workflow tools and what each layer does
• Connecting Supabase to Vercel
• Automating API health checks