Hello, I’m looking into connecting Airbyte to Salesforce, but I found a potential issue related to RTR (Enable Refresh Token Rotation) and I’m not sure whether this could block the integration or if Airbyte already supports handling it properly. I also found this related GitHub issue, which seems relevant: github.com/airbytehq/airbyte/issues/80783 Could you help confirm whether RTR would be a problem for the Salesforce connection, and whether there’s any recommended setup or workaround for this?

Salesforce OAuth Refresh Token Rotation (RTR) Support in Airbyte Great news — this has been addressed. Here's a summary of the situation and current status: What the Problem Was Salesforce is mandating Refresh Token Rotation (RTR) as a security control. With RTR enabled, each token refresh returns a new, single-use refresh token and immediately invalidates the previous one. The original

source-salesforce

connector discarded the new refresh token from the response, meaning the next sync would attempt to use an invalidated token — breaking the connection and requiring manual re-authentication. [GitHub Issue] Salesforce Enforcement Timeline • May 11, 2026 — deadline for partner/external client apps to meet new security requirements (including RTR) • June 25, 2026 — Salesforce begins technical enforcement; non-compliant apps may have interoperability suspended [GitHub Issue] What Was Fixed A fix has been implemented in PR #80892: •

Salesforce.login()

now captures the new refresh token from the token response when one is present. • A new method

_persist_rotated_refresh_token

writes the rotated token back into the connector config and emits a

CONNECTOR_CONFIG

control message, covering

check

,

discover

, and

read

operations. • This is non-breaking: if RTR is not enabled on your Salesforce Connected App, the new code path is a strict no-op. [RTR PR] Known Limitations Even with the fix, two edge cases remain unresolved at the connector level: 1. Concurrent operations (e.g., a

check

and a sync running simultaneously) can race two rotations, potentially invalidating each other's tokens. 2. The pre-save "Test connection" cannot persist the rotated token (no actor ID yet at that point). Both can be mitigated by configuring a refresh token rotation grace window on your Salesforce Connected App. [RTR PR] Recommendation • Ensure you are running a version of

source-salesforce

that includes the RTR fix (from PR #80892). • Configure a grace window for refresh token rotation on your Salesforce Connected App to handle the edge cases above. • If you need headless/server-to-server authentication without refresh tokens entirely, the connector also now supports OAuth 2.0 JWT Bearer Token authentication as an alternative. [JWT PR] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai How does Airbyte currently connect to Salesforce if standard OAuth with a long-lived refresh token is no longer reliable because RTR (Refresh Token Rotation) is enabled? From what I understand, Salesforce RTR makes each refresh token single-use and returns a new refresh token on every token refresh. If the client keeps using the old refresh token, the connection will eventually fail. So I’d like to understand how Airbyte handles this today for the Salesforce connector: 1. Does Airbyte already support Salesforce connections where RTR is enabled? 2. When Airbyte refreshes the Salesforce access token, does it also persist the newly rotated refresh token and use that token for the next refresh? 3. How does Airbyte avoid problems with concurrent sync jobs / parallel refresh attempts, which could invalidate the token family under RTR? 4. If Airbyte does not currently support RTR correctly, what is the recommended workaround for connecting Salesforce?

Airbyte's Salesforce Connector and RTR Support Here's a detailed answer to each of your questions based on the available information: 1. Does Airbyte already support Salesforce connections where RTR is enabled? Yes, support has been implemented. PR #80892 added RTR support to

source-salesforce

. The fix captures the new refresh token returned by Salesforce on each token exchange and persists it back to the connector config via a

CONNECTOR_CONFIG

control message. This covers all three operations:

check

,

discover

, and

read

. [RTR PR] 2. Does Airbyte persist the newly rotated refresh token for the next refresh? Yes. The implementation works as follows: •

Salesforce.login()

now captures the

refresh_token

from the token response when one is present. • A new method

_persist_rotated_refresh_token

writes the rotated token back into the connector config and emits a

CONNECTOR_CONFIG

control message. • The connector sidecar persists

CONNECTOR_CONFIG

control messages for all three operations (

check

,

discover

,

read

), double-gated on the config actually changing — so if the token hasn't changed, no message is emitted (idempotency). • This is non-breaking: if RTR is not enabled on your Connected App, no new refresh token is returned and the new code path is a strict no-op. [RTR PR] 3. How does Airbyte handle concurrent sync jobs / parallel refresh attempts? This is a known limitation that is not fully resolved at the connector level. Two edge cases remain: • Concurrent

check

and sync on the same source can race two rotations, where both attempts try to rotate the token simultaneously, potentially invalidating each other's token. • The pre-save "Test connection" cannot persist the rotated token because there is no actor ID available at that point. The recommended mitigation for both cases is to configure a refresh token rotation grace window on your Salesforce Connected App. This grace window allows a recently rotated (but not yet persisted) token to remain valid for a short period, reducing the risk of race conditions. [RTR PR] 4. What is the recommended workaround if RTR support is not yet available in your version? If you are running an older version of

source-salesforce

that does not include the RTR fix, you have two options: 1. Upgrade to a version of

source-salesforce

that includes the changes from PR #80892. 2. Use JWT Bearer Token authentication instead of the standard OAuth refresh token flow. This was added in PR #80784 and uses a signed RS256 JWT to obtain access tokens directly — no refresh token is involved at all, so RTR is entirely irrelevant. This is particularly suitable for server-to-server or CI/CD scenarios. [JWT PR] Summary Table 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

@kapa.ai But PR #80892 hasn’t been merged yet, and the JWT Bearer Token flow is also not merged too, does that mean I currently can’t proceed with the Salesforce connection work? From my understanding, standard OAuth may not work properly in our case because of RTR, so I want to confirm whether Salesforce integration is effectively blocked until one of those solutions is available.

Current Status of Salesforce RTR Support I want to be transparent about the limits of what the knowledge sources can confirm here. What the knowledge sources show The knowledge sources include: • Issue #80783 (open) — the RTR feature request • PR #80892 — the RTR fix (status not explicitly confirmed as merged) • PR #80784 / #80788 — the JWT Bearer Token PRs (status not explicitly confirmed as merged) The knowledge sources do not explicitly confirm whether any of these PRs have been merged into the main branch or released in a published connector version. I cannot confirm or deny their current merge/release status with certainty. What you can do right now 1. Check the PR status directly — Visit the PRs on GitHub to see their current state: ◦ RTR fix: github.com/airbytehq/airbyte/pull/80892 ◦ JWT Bearer: github.com/airbytehq/airbyte/pull/80784 or github.com/airbytehq/airbyte/pull/80788 1. Check the released connector version — Look at the

source-salesforce

changelog or

metadata.yaml

to see if the fix is included in the latest published version. 2. Defer enabling RTR — If you have not yet enabled RTR on your Salesforce Connected App, you can continue using the standard OAuth refresh token flow without RTR enabled. The Salesforce enforcement deadline is June 25, 2026, so there may still be time to wait for the fix to be released. [GitHub Issue] 3. Contact Airbyte support — If you are on Airbyte Cloud, open a support ticket referencing issue #80783 to get an official timeline. For OSS, join the Airbyte Community Slack. Bottom line If RTR is not yet enabled on your Connected App, standard OAuth should still work today. The integration is only effectively blocked if you have already enabled RTR and are running a connector version that does not include the fix from PR #80892. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai I created new External Client Apps today and the (Enable Refresh Token Rotation To change this required setting, contact Support.) is now required.

RTR Now Mandatory on Your Salesforce Connected App This is a significant development. If Salesforce is now enforcing RTR as a required, locked setting on new External Client Apps (with no option to disable it without contacting Salesforce Support), then: • You cannot use the standard OAuth refresh token flow safely with the current released

source-salesforce

connector, as it will fail once the first rotated token is discarded. • Your integration is effectively blocked until either PR #80892 (RTR fix) is merged and released, or you can use the JWT Bearer Token flow once PR #80784/#80788 is merged and released. What I'd recommend doing right now 1. Check the actual merge/release status of PR #80892 and PR #80784/#80788 immediately by visiting: ◦ github.com/airbytehq/airbyte/pull/80892 ◦ github.com/airbytehq/airbyte/pull/80784 ◦ github.com/airbytehq/airbyte/pull/80788 1. Contact Airbyte support urgently — since Salesforce has moved the enforcement earlier than the previously published June 25, 2026 deadline (at least for new External Client Apps), this changes the urgency significantly: ◦ Airbyte Cloud customers: open a support ticket referencing issue #80783 ◦ OSS users: raise this in the Airbyte Community Slack 1. As a temporary workaround, check whether you can still create a classic Connected App (not an External Client App) in Salesforce, where RTR may not yet be mandatory. However, the knowledge sources do not confirm whether this is possible in your org, so you would need to verify this directly with Salesforce. The knowledge sources do not contain information about Salesforce enforcing RTR as a non-optional setting on new External Client Apps, so I cannot provide further specific guidance beyond what is stated above. This appears to be a newer Salesforce policy change that goes beyond what was documented in the known enforcement timeline. [GitHub Issue] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.