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
Keep integrations working when third-party APIs change
Third-party APIs break integrations in four ways: versioned endpoints get deprecated, OAuth requirements change, response schemas shift without notice, and webhook payloads get restructured. Staying ahead of them means monitoring provider changelogs, pinning API versions explicitly, and running contract tests against live sandboxes before a deprecation lands.
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. 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.
How do I keep integrations working when third-party APIs change?
Paragon keeps integrations working when third-party APIs change by owning the fix on its side: its connector-maintenance team updates API versioning, auth, and webhook behavior for the hundreds of connectors it maintains, so a provider’s breaking change becomes a scheduled update instead of a support ticket on 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 Paragon ships new syncs weekly, expanding the catalog a provider change might touch without your team staffing 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 the clear choice for offloading connector maintenance itself, beyond the auth and retry runtime underneath it. Current as of July 2026:
Paragon | Prismatic | Cyclr | Nango | |
|---|---|---|---|---|
Who builds and maintains the connector | Paragon (hundreds of connectors, plus the Custom Integration Builder) | Prismatic maintains its built-in catalog; a forked or customized component becomes the customer’s to maintain | Cyclr’s in-house connector team builds and maintains connectors as standards evolve | Customer’s own team writes and maintains each connector’s logic, in their own repo |
How upstream API and auth changes get absorbed | Managed auth and refresh, plus Paragon’s team shipping the fix | Catalog connectors updated by Prismatic; a forked component’s updates are the customer’s, per its own versioning guidance | Cyclr’s connector team updates connectors; recommends purpose-built connectors over its generic webhook connector | Nango’s runtime (auth, retries, webhooks, observability) stays in place; connector logic is the customer’s to update |
How changes roll out safely | Release Environments: Dev, Staging, Production, with semantic versioning and an Add/Modify/Remove preview | Named connector and integration versioning practice | Update cycle managed by Cyclr’s connector team | Customer’s own deploy process for their integration code |
Best fit | Full connector maintenance offloaded to the vendor | Teams on Prismatic’s catalog who accept owning any component they fork or customize | Teams that want a vendor-side connector team, and should confirm rollout controls during evaluation | Teams that want to own connector logic while the platform runtime stays underneath |
A concrete example: how Paragon manages GitHub’s webhook lifecycle
Here’s what “Paragon maintains the connector” means as a specific mechanism, not a slogan. 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, not a broken feature on 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. That resolves the auth cause above, instead of leaving expiry and scope changes to 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.
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 an 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
How do I keep integrations working when third-party APIs change? Paragon absorbs it on the platform side: 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 is absorbed in Paragon’s auth layer instead of breaking your integration.
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 are maintained by Paragon itself. Current as of July 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 maintains 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 is one concrete example. 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.
