Keep integrations working when third-party APIs change

Paragon keeps integrations working when a third-party API changes, maintaining all 130+ of its connectors itself so a provider's breaking change is Paragon's engineering problem, not something that lands on your backlog. The claim isn't abstract: for GitHub, Paragon uses a connected user's own OAuth token to create, update, and remove that user's webhook subscriptions automatically, a documented mechanism covered in detail below. Without that layer, when GitHub ships a new API version, rotates an OAuth scope, or quietly changes a rate limit, every webhook subscription built against the old behavior starts failing, and someone on your team has to find which of hundreds of customer connections broke and ship a fix before support tickets pile up.

This is one facet of what an integration platform does day to day: keeping already-shipped connectors working as providers change their APIs. The full mechanics of receiving and retrying webhook events, and the complete platform taxonomy behind ActionKit, Managed Sync, and Workflows, are covered separately in how integration platforms make integrations easier.

Why third-party APIs break integrations

Three causes show up across nearly every SaaS provider's API changelog. Versioning and deprecations: a provider ships a new API version or removes fields and endpoints an integration depended on. Auth changes: a provider rotates an OAuth scope, requires new app review, 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 the integration's contract technically changed, but the behavior did. Any one of these can turn a working integration into a support ticket overnight, and the customer using your product has no way to know whether the failure is theirs, yours, or the third-party provider's.

Who keeps an integration working when a third-party API changes?

Paragon does, for the 130+ connectors it maintains: Paragon owns the fix on its side, so your team isn't maintaining that connector path. That coverage runs across Paragon's connector catalog, and 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 this same connector layer, with managed authentication and token refresh built into every sync, and Paragon ships new out-of-the-box syncs every week, so the catalog a provider change might touch keeps expanding on a cadence your team didn't have to staff for.

The model is build once, cover the category. Paragon doesn't just wrap a single provider's API; it normalizes a whole category, so an update to Salesforce's API or a change to HubSpot's auth flow gets absorbed inside the connector Paragon maintains for that category rather than surfacing as a broken integration in your product. Copy.ai's CTO and co-founder Chris Lu described the alternative this way: "We would have had to hire a dedicated team of engineers, building this out internally would have taken at least half a year. With Paragon, one engineer knocked out multiple integrations within a few weeks." That's the maintenance model holding up at initial build, and again every time a provider changes something afterward.

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 whatever the trigger's configuration requires. If a user changes which repositories they want events from, or GitHub changes how a scope behaves, Paragon updates or replaces the underlying webhook subscription without the user re-authorizing from scratch and without your team writing code against GitHub's webhook-management endpoints directly. The mechanism requires the repo scope for repository-level access or admin:org_hook for organization-level access, and Paragon's GitHub integration docs recommend GitHub Apps over OAuth Apps wherever higher, scalable rate limits matter.

This is the same pattern Paragon applies across its catalog: own the provider-specific mechanics, which scope a given operation needs, which endpoint version is current, how a webhook subscription actually gets created and torn down, so a provider's API change shows up as a connector update on Paragon's side instead of a broken feature on yours.

How managed auth and refresh absorb upstream auth changes

As long as a third-party API uses API keys or OAuth, Paragon owns the end-to-end authentication and refresh flow, so a provider rotating a token or changing a refresh cadence doesn't surface as an outage in your product. That handles the auth cause from the list above structurally: token expiry and scope changes get absorbed inside Paragon's auth layer instead of failing silently inside your own credential store.

The same durability logic applies to Managed Sync's data layer. Syncs are engineered to handle upstream API issues, rate limits, and temporary unavailability through intelligent retry scheduling and periodic full refreshes, plus automatic pagination and error handling, so a provider tightening a rate limit or dropping a connection mid-sync doesn't require a manual re-run on your side. The exact retry timing and delivery guarantees for real-time webhook events are their own topic, covered in Paragon's webhook infrastructure.

Rolling out fixes safely with Release Environments

Fixing a connector is only half the problem. Shipping that fix, or any integration change, without breaking customers still running the previous version is the other half, and that's what Release Environments are for. Paragon separates Development, Staging, and Production into distinct environments, each with its own project ID, signing key, and connected-user data. A release can't deploy with a version number lower than what's already live, and before deployment, Release Preview shows every change categorized as Add, Modify, or Remove, with Warning messages that have to be resolved before deploy and Informational messages that flag anything user-impacting. Staging gives you a read-only environment to verify the change before it reaches real customer connections. Once Production is designated, it becomes read-only, and that designation can't be undone.

This is worth being precise about: Release Environments is how you version your own integration configuration, whether that's a workflow you built or a Custom Integration you're maintaining. Paragon's own patching of the 130+ connectors it maintains happens separately, ahead of anything reaching your Development environment. Paragon absorbs the provider-side breakage on the connectors it owns; Release Environments gives you the same safe-rollout discipline for the integration logic you own on top of it.

How Paragon fits

Say GitHub deprecates a webhook payload field an integration depends on, or changes what an OAuth scope covers for organization-level hooks. On Paragon's side, that lands as a ticket for the connector-maintenance team, not for yours: the GitHub connector gets updated using the same OAuth-token-based webhook-subscription mechanism described above, and Paragon owns that fix on its side rather than your team maintaining the connector path.