April 15, 2026
By Conor Brennan-Burke · Founder
Your Slack connector worked great. It pulled conversations, threaded messages, channel history. Your agent could answer questions about what the team discussed last week.
Then Slack deprecated the files.upload API method. Newly created apps lost access in May 2024. Existing apps had to migrate to a two-step upload flow using entirely different endpoints before the method sunset in November 2025, a deadline Slack itself adjusted along the way. Around the same time, Slack announced retirement timelines for legacy custom bots and classic apps, timelines that have also shifted more than once.
If you maintained your own Slack connector, that was your problem to fix. If you didn't notice, your agent quietly lost access to data. No error. No alert. Just stale memories and wrong answers.
Connectors are not set-and-forget. They are ongoing maintenance commitments, and the cost compounds with every integration you add.
The phrase "we support 40 integrations" sounds like an asset. In practice, each connector is a liability. Building one takes weeks. Maintaining it takes forever.
The numbers are sobering:
Cost category | Per connector | Source |
|---|---|---|
Initial build | $28,000-$36,000 (6-8 weeks) | |
Annual maintenance | ~$36,000/year | |
Engineering hours (build) | 150 hours | |
Engineering hours (maintain) | 300 hours/year | |
Support tickets | ~150/year at 2 hrs each | |
Total annual cost | $50,000-$150,000 |
Per Composio's analysis, initial development accounts for less than 30% of total lifetime cost.
Scale that up and the math gets uncomfortable. Twenty integrations at Merge's 150-hour estimate means 3,000 engineering hours just to build, more than one developer working full-time for a year. Maintenance adds at least another full-time equivalent on top.
Building a connector is a one-time project. Maintaining it is a permanent headcount expense that grows with every integration you add.
Third-party APIs change constantly. A large-scale study of 317 real-world Java libraries across roughly 9,000 releases found that 28% of API changes break backward compatibility. These are not rare events. They are the normal lifecycle of any API.
Authentication is the most fragile layer. OAuth token refresh logic fails silently: tokens expire, the system retries without prompting re-authentication, and the connector appears functional while actually returning nothing. Race conditions in concurrent token refreshes can permanently lose valid refresh tokens, making future authentication impossible without user intervention.
Providers change their auth requirements regularly. Airtable forced a migration from API key authentication to OAuth and personal access tokens. HubSpot deprecated its broad Contacts scopes in favor of granular alternatives. Each change means updating your OAuth flows, testing against production accounts, and deploying, usually on the provider's timeline, not yours.
Endpoints get deprecated. Response formats change. New required parameters appear.
Atlassian removed the name and key fields from Jira user objects and replaced them with a single accountId field as part of its user privacy changes. Any connector parsing the old format broke. Meta's Marketing API retires versions on a roughly annual cycle, sometimes leaving developers compressed migration windows.
Slack's changelog lists dozens of deprecations, from API method retirements to complete platform rewrites. The files.upload deprecation. The RTM API migration. The workspace apps retirement. Each one required connector updates.
Rate limits change without warning. New limit categories get introduced. Backoff requirements shift. When your connector hits a limit it didn't know about, it either fails hard (good, you notice) or backs off so aggressively that sync falls hours behind (bad, you don't).
Fields get added, renamed, or removed. Types change. Nested structures reorganize. Paragon's engineering team reports dedicating "about a sprint every month or two" specifically to handling third-party API changes on behalf of their customers.
These are the hardest to catch. Pagination order changes. Default values shift. Sort behavior reverses. No error is thrown. The data comes back, it just comes back differently. Your connector processes it normally and stores subtly wrong results. You find out when a user complains.
When a connector breaks, the failure rarely announces itself. In our experience and across industry reports, unmanaged API changes are one of the most common causes of integration failures, and each incident can consume days of emergency engineering work. But the failures you notice are not the dangerous ones.
The connector encounters an error, logs it somewhere nobody checks, and stops syncing. No alert fires. The agent continues answering questions using whatever data it last received, which might be days or weeks old. The user asks about yesterday's meeting. The agent has no record of it. Neither the user nor the agent knows why.
This is the worst failure mode because the system appears healthy. There is no error page. No timeout. Just quietly stale data producing subtly wrong answers.
Some data types sync while others fail. Emails come through but calendar events don't. The agent recommends scheduling a meeting at 2 PM on Thursday, unaware that the user is already booked. Partial sync creates a distorted picture that is worse than no data at all, because the agent has high confidence in incomplete information.
Schema mismatches cause type coercion errors that silently corrupt stored values. A numeric field starts returning strings. A date format changes from ISO to Unix timestamps. The connector writes the wrong type into your memory store. Now every query that touches that field returns garbage, and you won't know until someone traces a wrong answer back to the corrupted record.
The connector hits limits, backs off, and falls behind. Sync freshness degrades gradually from minutes to hours to days. There is no hard failure point. Just a slow slide into staleness. The degradation is so incremental that it evades threshold-based alerts.
The most dangerous connector failures are the ones where nothing visibly breaks. The agent keeps answering, just with outdated, incomplete, or corrupted data.
If you are maintaining your own connectors, there are patterns that reduce (but do not eliminate) the maintenance burden.
Never assume field presence. Handle unexpected types gracefully. Treat every API response as potentially different from what your schema expects. When a field disappears or changes type, your connector should log the anomaly and continue with a safe default rather than crash or silently corrupt data.
"No errors" is not the same as "working." Active health checks should verify that data is actually flowing, not just that the connector process is running. Check record counts. Check that the most recent synced timestamp is within an acceptable window. A connector that runs without errors but receives no new data has failed, even if it doesn't know it.
Alert on sync failures, sync delays, and unusual patterns. Google Drive push notification channels expire after at most seven days and must be recreated. If your monitoring only checks for explicit errors, an expired channel will silently stop delivering updates with no alert.
Set up alerts for: absolute sync failure, sync delay beyond threshold (for example, no new records in 24 hours for a daily-active source), and unexpected drops in record volume.
When a connector fails, surface old data with a staleness indicator rather than pretending everything is current. Let the agent, and the user, know the information might be out of date. A qualified answer ("Based on data from three days ago...") is more honest and more useful than a confident wrong answer.
Composio's TCO model budgets 10-20 hours per month of maintenance for a single moderately complex integration. Stable connectors need less. Connectors mid-migration need far more. Multiply by connector count and the math turns into headcount: at 40 connectors, even conservative estimates put you at one or more full-time engineers dedicated to maintenance alone. That's before on-call rotations, customer escalations, or major breaking changes.
Dust, which has published lessons from more than 1,000 enterprise AI deployments, found a consistent pattern. Doctolib built an internal AI assistant that gained 800 active users. It worked well. But the feature backlog, driven in large part by integration maintenance and new connector demand, grew so fast that the team estimated it would need to triple in size to keep parity with what a platform offered out of the box. Wakam, with a small data science team, reached the same conclusion: each new feature required weeks of development, and the market moved faster than they could build.
The maintenance workload is not a temporary phase. It is a permanent cost that increases every time you add a connector and every time a provider ships an API update.
The build-vs-buy question for connectors is not the same as the general build-vs-buy question for your product. Your product is your differentiation. Your Slack connector is not.
Custom connectors give you full control over the integration logic. That control comes with full ownership of the maintenance burden: every OAuth update, every schema change, every rate limit adjustment.
Managed connectors give you less control over implementation details. In exchange, the maintenance shifts to the provider. When Slack changes their API, that is their problem, not yours.
The threshold, per Composio's analysis, is roughly 5-10 integrations. Below that, custom connectors are manageable. Above that, the compounding authentication and maintenance overhead typically makes a platform more cost-effective. Composio estimates teams ship integrations 4-6x faster with a platform approach.
At Hyperspell, we maintain 50+ integrations across communication, email, calendar, CRM, project management, code, documents, and more. When a provider ships a breaking change, our team handles the migration. Your code does not change. A single SDK call queries across all connected sources:
from hyperspell import Hyperspell
client = Hyperspell(api_key="API_KEY", user_id="user_123")
response = client.memories.search(
query="latest project status updates",
sources=["slack", "gmail", "jira"]
)
When a source has an issue (an expired OAuth token, a sync delay, an API outage), the query response includes per-source error details while still returning results from working sources:
response = client.memories.search(
query="what did the team discuss about the launch?",
sources=["slack", "google_calendar", "notion"]
)
for error in response.errors:
print(f"Source issue: {error['error']}: {error['message']}")
# Results from working sources are still returned
print(response.documents)
Hyperspell Connect handles the OAuth flows for your users, including account connection, token management, and re-authentication, through a pre-built UI you embed in your app. You do not write or maintain OAuth code.
Whether you build or buy, some practices reduce your exposure to connector failures.
Prioritize by business impact. Not all connectors are equal. A broken Slack connector for a team communication agent is critical. A broken analytics connector for a reporting agent is annoying but survivable. Allocate monitoring and maintenance effort accordingly.
Monitor provider changelogs. Most major API providers publish changelogs and deprecation timelines. Slack, Google, HubSpot, Salesforce, and Atlassian all publish advance notice. The teams that get burned are the ones that don't read the notices until something breaks.
Have runbooks. Common failures should have documented resolution procedures. OAuth token expired? Runbook. Rate limit hit? Runbook. Schema field disappeared? Runbook. The goal is to reduce incident resolution from hours of diagnosis to minutes of execution.
Audit your connector count. Run periodic reviews of which connectors are actually used and which can be retired. Dead connectors still carry a maintenance cost: they break when APIs change whether or not anyone uses them.
The connector maintenance burden is real, ongoing, and growing. Every integration you add is a commitment to monitor, update, and fix indefinitely. Understanding that cost honestly, before you start building, is one of the most important architectural decisions you can make for your agent's data infrastructure.
How often do third-party APIs break? Frequently. A large-scale study of 317 libraries and roughly 9,000 releases found that 28% of API changes break backward compatibility. Major providers like Slack, Google, and Atlassian ship breaking changes multiple times per year.
What is the real cost of maintaining one API connector? Composio estimates around $36,000 per year per connector for maintenance alone. Merge.dev reports 300 engineering hours per year plus roughly 150 support tickets at 2 hours each. The total including personnel and partnerships ranges from $50,000 to $150,000 annually per integration.
When should I buy integrations instead of building them? The typical threshold is 5-10 integrations. Below that, custom connectors are manageable. Above that, the compounding OAuth complexity, schema change handling, and rate limit management make a managed platform more cost-effective. Composio estimates time-to-market can be 4-6x faster with a platform approach.
What is the most dangerous connector failure mode? Silent data loss. The connector stops syncing but no error is visible. The agent continues answering questions with stale data, and neither the user nor the system knows anything is wrong until someone gets a wrong answer and traces it back to the broken connector.