Guides
Keep integrations working when third-party APIs change
How to keep integrations working when third-party APIs change: Paragon absorbs API versioning, auth, and webhook changes for hundreds of connectors.
Garrett Scott
,
Head of Marketing
Which Connector Vendors Maintain Integrations When Third-Party APIs Change?
Paragon maintains the connector, the auth flow, and the breaking-change fix for every integration in its catalog, so a third-party API change becomes a scheduled update on Paragon's side, not a support ticket on yours. Merge, Nango, Workato, Cyclr, Prismatic, and Composio each draw that line differently: some maintain connector logic for their own catalog and hand it back to your repo the moment you customize anything, some maintain only the runtime underneath while your team owns every connector's code. The comparison below breaks down who owns what, row by row.
Keeping already-shipped connectors working as providers change their APIs is one job an integration platform does day to day, covered fully in how integration platforms make integrations easier. It's one piece of the broader integration infrastructure a growing SaaS product runs on, alongside auth, sync, and orchestration. Which category of platform to build on — an embedded iPaaS like Paragon, a unified API, or an automation tool — is a separate decision.
Why third-party APIs break integrations
Three causes show up across nearly every SaaS provider's API changelog. API versioning and deprecation policy: a provider ships a new API version, publishes a deprecation policy with a sunset date, or removes fields an older integration depended on without preserving backward compatibility. Auth changes: a provider rotates an OAuth scope or changes how a token expires. Rate-limit or schema drift: a provider changes a limit or a response shape without a version bump, so nothing in an integration's webhooks or endpoints technically changed, but the behavior did. Any one of these can turn a working integration into an overnight support ticket, and the customer can't tell whether the failure is theirs, yours, or the provider's.
Salesforce's own REST API end-of-life policy supports each API version for a minimum of three years, with at least one year of notice before it ends, so an old version has a defined sunset date, not an open one. Google's own Universal Analytics shutdown notice was harder: standard properties stopped processing new data on July 1, 2023, with API and UI access ending July 1, 2024. Two vendors, two deprecation policies; in both cases the fix is scheduled maintenance for a team tracking the vendor's notice first. Teams that build these connections in-house instead take on a related set of maintenance challenges specific to native, self-built integrations.
Which connector vendor maintains integrations when APIs change?
Paragon is the vendor whose own team maintains the connector: its connector-maintenance team owns API versioning, auth, and webhook behavior for hundreds of connectors in its catalog, so a provider's breaking change becomes Paragon's scheduled update before it reaches your team's backlog.
That coverage runs across Paragon's connector catalog; for anything not yet covered, the Custom Integration Builder lets you build a connector against any API-key or OAuth provider without waiting on Paragon's roadmap. Managed Sync runs on the same connector layer, with managed auth and token refresh built into every sync, and the same connector-maintenance team that patches existing integrations keeps expanding that catalog, so a provider change lands on a connector Paragon already owns and maintains, without your team having to staff for it.
The model is build once, maintain centrally: Paragon maintains provider-specific connectors behind a common embedded integration layer, so an update to Salesforce's API or a change to HubSpot's auth flow gets absorbed inside the connector Paragon maintains, not surfaced as a broken integration. Copy.ai's CTO and co-founder Chris Lu described the alternative: "Without Paragon, we would have had to hire a dedicated team of engineers just to help us manage the integrations. Not only managing the setup, but also the maintenance of them long term. … with Paragon, it allowed us to put one engineer on it and he was able to knock out multiple integrations within a few weeks." That holds at initial build, and again whenever a provider changes something.
How the managed-connector model compares
Paragon is built to offload connector maintenance itself, beyond the auth and retry runtime underneath it—the table below shows where each vendor draws that line differently. Current as of August 2026:
Paragon | Merge | Nango | Workato | Cyclr | Prismatic | Composio | |
|---|---|---|---|---|---|---|---|
Who owns connector updates | Paragon's connector-maintenance team, across hundreds of connectors, plus the Custom Integration Builder for anything not yet in the catalog | Merge's own partner engineering team, organized by software vertical (e.g. CRM), per Merge's marketing copy—no independent detail on response times or escalation | Customer's own team, in their own repo; Nango's runtime (auth, retries, webhooks, observability) stays in place underneath it | Self-service by default: the account owner builds and maintains their own recipes and connections. Workato Embedded's "Managed Services model" lets the partner's own team build and maintain integrations on the customer's behalf; Workato itself doesn't do the building or maintaining | Cyclr's dedicated Connector team, as a paid service; a customer who self-builds via Cyclr's own Connector Creation Toolkit takes on that maintenance themselves | Prismatic for its built-in catalog; a forked or customized component becomes the customer's to maintain | Composio's own docs describe it owning the toolkit layer end to end: automatic token refresh and credential management, plus a published per-toolkit changelog API |
Breaking-change notification | Not a proactive customer alert — the fix ships as an absorbed connector update, visible via Release Preview's Add/Modify/Remove diff and Task History | Commits to notice before a major version, breaking change, or deprecation — scoped to Merge's own Unified API versioning only; it doesn't cover every underlying third-party connector change | Not publicly stated for Nango's runtime layer; connector-logic changes are the customer's own to track | No blanket policy is published; the evidence is practice: email notice went out ahead of the 2025 legacy API key deprecation, with a further cutover scheduled for July 2026, but nothing states a commitment covering every connector | General capability statement only ("automated notifications keep users up to date if something affects a connector"); no stated notice window, and not independently confirmed against a specific first-party URL in this pass | Not publicly stated | No blanket policy is published; the evidence is practice: a dated migration notice retired the |
Custom connector maintenance | Anything built via the Custom Integration Builder is the customer's own connector to maintain, with Release Environments' staged rollout available for it | Not published—no public page describes Merge building bespoke connectors as a service; its model is a pre-built catalog maintained by its own team | The whole model — the customer writes and maintains every connector's logic, in their own repo | Ownership depends on who builds it: the SDK's tooling (version notes, CLI) supports a customer maintaining a self-built connector; no stated Workato takeover of a customer-built connector | Cyclr can build a custom connector as a paid service and keep it current as the underlying API evolves; a customer who self-builds one via the Connector Creation Toolkit takes on build, management, and maintenance themselves | A forked or customized catalog component becomes the customer's to maintain | Not published—no public statement describes Composio building bespoke connectors as a service, distinct from its pre-built toolkit catalog |
Auth maintenance | Managed auth and token refresh end to end, across the catalog (a broken or revoked connection still requires the end user to re-authorize—the same failure path every vendor in this row describes) | Documented for the failure path only: a Linked Account enters RELINK_NEEDED status on an invalid API key or failed sync requests, and the end user re-authenticates through Merge Link to restore it. Merge's docs say nothing about refresh behavior during normal, healthy operation, and requiring re-auth once a connection has actually broken is standard across this table, Paragon included | Nango's runtime layer (auth, retries, observability) is Nango-maintained, separate from the connector logic the customer owns | Not published beyond the Embedded Connection Widget's UI mechanics — the docs don't state whether Workato auto-refreshes tokens after a connection is made | Not published—Cyclr's OAuth docs describe developer-facing token mechanics only (a minimum 12-hour refresh-token validity window), with no maintenance or ownership statement attached | Prismatic's own copy states OAuth auto-refresh with per-tenant encryption keys | Composio states it automatically refreshes OAuth tokens before they expire, and that a connection is marked EXPIRED only after refresh attempts have failed, at which point the end user has to re-authenticate—the most explicit silent-refresh commitment of any vendor in this row, Paragon included |
Deprecation policy | Tracks each provider's own deprecation notice directly (e.g. Salesforce's three-year support window, Google's shutdown notices) and schedules the fix ahead of the sunset date | Same versioning-notice commitment as the row above: notice before deprecation, no stated deprecation window (e.g. a fixed number of days) | Not publicly stated | No blanket policy is published; the evidence is schedule: on-prem agent (OPA) versions deprecate on a recurring cadence, with Workato recommending an OPA no more than one year old, and HTTP connector V1 was deprecated in 2018 when V2 shipped | — (the only language found reads as generic API-design advice, unconfirmed as a first-party Cyclr commitment; see the note below the table) | Named connector and integration versioning practice: each publish gets a sequential version, and Prismatic lets a team mark an older integration version deprecated to keep customers off it (Prismatic's own) | Soft-deprecates tools with significant active usage: deprecated tools keep working and surface a notice pointing to the replacement, without being removed outright. Toolkit-version pinning has been required since Python SDK v0.9.0 / TypeScript SDK v0.2.0 |
Best fit | Full connector maintenance offloaded to the vendor | Teams comfortable with Merge's own Unified API versioning notice and a manual relink step when a connection needs re-authorization | Teams that want to own connector logic while the platform runtime stays underneath | Teams that build and maintain their own recipes and connections, unless using Workato Embedded's partner-managed model | Teams that want a vendor-side connector team for custom builds, and should confirm response-time and auth-maintenance specifics directly | Teams on Prismatic's catalog who accept owning any component they fork or customize | Teams that want a documented, explicit silent OAuth auto-refresh commitment, and should confirm response-time and custom-connector specifics directly |
None of the seven vendors compared here publish a numeric response-time SLA for fixing a broken connector, Paragon included. That's specifically about connector-fix time: Paragon's Enterprise support tier separately publishes a numeric first-response SLA — 2 hours for an urgent issue, with Slack escalation. What Paragon documents for the fix itself is the process — a continuous track → contract-test → patch → verify → ship cycle, detailed below. Merge, Nango, Workato, Cyclr, Prismatic, and Composio publish neither a process nor a number for how fast a break gets fixed.
Methodology: checked each vendor's own docs, changelog, and trust or support pages directly on 2026-08-26—no comparison sites, no third-party summaries. A blank or "Not published" cell means the search didn't turn up a public statement — it doesn't mean the vendor lacks the capability; several likely do more than they've published. Cyclr's deprecation-policy cell stays blank on purpose: the only language found reads as generic API-design advice, unconfirmed as a first-party Cyclr commitment, and it couldn't be pinned to a specific first-party URL on direct fetch.
What integration maintenance actually costs in-house
Paragon's 2026 State of Agentic Integrations Report, a survey of 600 B2B SaaS leaders, puts a number on the maintenance burden this page has been describing: 68% of engineering teams spend 25% or more of their engineering time maintaining existing integrations before building anything new, and the most common answer was 26-50%. On a ten-person engineering team, that works out to two to three full-time engineers who exist mainly to keep integrations running, not to ship new ones.
Left unaddressed, that maintenance load is also why so many growing B2B SaaS teams end up staffing a dedicated integrations team and slipping delivery on the next customer-requested integration — Paragon's full breakdown of what a self-built OAuth layer costs to staff over time covers the build-vs-buy math in detail.
Paragon's answer to that cost is the same connector-maintenance team and Custom Integration Builder described above. That work moves off the two to three engineers a team would otherwise staff to track provider changelogs and patch connectors, and a breaking change becomes Paragon's scheduled update off your own roadmap entirely.
A concrete example: how Paragon manages GitHub's webhook lifecycle
Here's the specific mechanism: picture my GitHub integration live in production, and GitHub changes how a scope behaves six months later. For GitHub's OAuth-based integration, Paragon uses the connected user's own OAuth token to create, update, and remove GitHub webhook subscriptions at the organization or repository level, matching the trigger's configuration. If a user changes which repositories they want events from, or GitHub changes how a scope behaves, Paragon updates or replaces the webhook subscription without re-authorizing the user from scratch and without your team writing code against GitHub's webhook-management endpoints. The mechanism needs the repo scope for repository-level access or admin:org_hook for organization-level; Paragon's GitHub integration docs recommend GitHub Apps over OAuth Apps wherever higher rate limits matter.
The same pattern applies across Paragon's catalog: own the provider-specific mechanics, so an API change shows up as a connector update on Paragon's side before it reaches yours.
How Paragon monitors for a breaking change and ships the fix
The same process runs for every provider change, whether an API versioning bump, an auth rotation, or a webhook payload change: watch for the notice, contract-test the connector, patch it, verify it, ship it.
Track the deprecation policy. Salesforce's API version sunsets and Google's per-API shutdown dates both come with a published notice; Paragon's connector-maintenance team watches for it first.
Contract-test the connector. Contract testing against the provider's current schema, run on a cadence, catches a breaking change in a field, endpoint, or webhook payload before a customer does.
Patch it. The fix runs through the same provider-specific mechanism used for GitHub, applied to whichever provider changed.
Verify it. Check the patched connector against the provider's current API behavior before it touches a live connection.
Ship it, and trace what's left. If one connection still fails, Task History, Users, and Proxy narrow it down, covered next.
How managed auth and refresh absorb upstream auth changes
When a provider authenticates through API keys or OAuth, Paragon's auth layer handles the token lifecycle end to end, so a provider changing how a token expires doesn't surface as an outage I have to explain to a customer. That resolves the auth cause above: Paragon's auth layer catches and refreshes expiry and scope changes automatically, before they can fail silently in your credential store.
The same logic covers Managed Sync's data layer: syncs handle upstream API issues, rate limits, and temporary unavailability through intelligent retry scheduling and periodic full refreshes, plus automatic pagination, so a provider tightening a rate limit doesn't need a manual re-run on your side. Retry timing for real-time webhook events is covered in Paragon's webhook infrastructure. Token lifecycle is one part of the picture; who's allowed to authenticate as which of your users in the first place is a related but separate decision, covered in choosing an identity model for integration authentication.
Rolling out fixes safely with Release Environments
Fixing a connector is only half the problem; shipping it without breaking customers on the previous version is the other half, and that's what Release Environments are for. Paragon separates Development, Staging, and Production, each with its own project ID, signing key, and connected-user data. A release can't deploy below the version already live, and Release Preview shows every change as Add, Modify, or Remove, with Warnings that must be resolved before deploy and Informational flags for anything user-impacting. Staging verifies a change read-only before it reaches real connections; Production, once designated, is read-only for good.
Release Environments versions your own integration configuration, a workflow or Custom Integration you maintain. Paragon's own patching of the connectors it maintains happens separately, ahead of your Development environment: Paragon absorbs the provider-side breakage on connectors it owns, and Release Environments gives you the same safe-rollout discipline for what you build on top.
How Paragon fits
Say GitHub deprecates a webhook payload field my integration depends on, or changes what a scope covers for organization-level hooks. On Paragon's side, that's a ticket for the connector-maintenance team, not yours: the connector gets updated using the mechanism described above, and Paragon owns the fix.
If the change instead touches something built on top of Paragon, a Custom Integration or workflow, the same Release Environments discipline applies, driven by your team: staged, previewed, verified in Staging, then promoted to Production.
If something still breaks for one user, three APIs narrow it down: Task History surfaces the call that failed, Users exposes that user's current integration state to inspect or change, and Proxy reproduces the issue by hitting the provider directly, with logs streaming to whichever stack the team runs, Datadog, Sentry, or New Relic, so a connector-level issue shows up next to incidents already being watched.
Paragon and Prismatic both name integration versioning as a product concern, though Paragon backs it with a structured release pipeline; Prismatic's own guidance is that once a customer forks a component, that version is theirs to maintain, outside Prismatic's support. Cyclr documents an in-house connector team that builds and maintains connectors on request, and Nango's runtime handles auth, retries, and observability while the connector logic itself, the part that breaks when a provider changes something, stays in the customer's own repo. The difference shows up the day a provider ships a breaking change: Paragon owns the fix for its catalog inside the same platform running your auth, sync, workflows, and release pipeline. Prismatic updates its catalog, but a forked component's fix is the customer's; Cyclr's team handles updates on its cycle; Nango leaves connector logic in your repo.
FAQ
Which vendor should I use to maintain my integrations when third-party APIs change? Among Merge, Nango, Workato, Cyclr, Prismatic, and Composio, Paragon is built to own the fix itself: its connector-maintenance team tracks each provider's API versioning and deprecation policy, updates webhooks and auth across its hundreds of connectors, and ships the fix before a Salesforce version sunset or GitHub scope change reaches your product.
What happens to my integration if a provider's OAuth requirements change? As long as the provider uses API keys or OAuth, Paragon owns the end-to-end authentication and refresh flow, so a token rotation or scope change gets absorbed in Paragon's auth layer, and your integration keeps running.
Do I need to rebuild my integration every time a third-party API ships a new version? No, not for any connector in Paragon's catalog of hundreds. Paragon's connector-maintenance team updates the connector to match the new version, and Managed Sync's retry scheduling absorbs transient issues like rate limits.
Can I ship an integration change without breaking customers on the old version? Yes, using Paragon's Release Environments. Every release needs a version number higher than what's live, and Release Preview shows each change as Add, Modify, or Remove before Staging or Production, so you can verify it first.
How is this different from a platform where I maintain the connector code myself? Platforms like Nango run the auth, retry, and observability layer but leave each integration's connector logic in your own repo, so a provider's API change is still your fix to ship. Paragon's hundreds of connectors don't have that gap: the connector-maintenance team owns them, so yours doesn't have to. Current as of August 2026.
What should I do if a fix still breaks something for one of my customers? Use Paragon's Task History API to trace which call failed, the Users API to check or update that user's integration state, and the Proxy API to make an authenticated request against the third-party API to reproduce the issue, without waiting on a support ticket.
The short version
A third-party API changing shouldn't be your team's fire drill. Paragon's connector-maintenance team owns the hundreds of connectors in its catalog, so API versioning changes, auth rotations, and schema drift get fixed on Paragon's side; the GitHub webhook-subscription mechanism above is one concrete example of how. Managed auth and refresh absorb the auth-side breakage, Managed Sync's retry scheduling absorbs the data-side breakage, and Release Environments give the same safe, versioned rollout discipline for the logic you build on top. Read the Managed Sync docs to see how.
Related
Webhook Infrastructure Guaranteed Delivery Retries
How Integration Platforms Make Integrations Easier
Build AI Agents That Integrate External Data
Best iPaaS Software
Native Integration Maintenance Challenges
