QuickBooks integration disconnecting daily — authentication issue?

From a governance perspective, we require stable integration connectivity for our financial audit trail. Since Thursday of last week, our QuickBooks Online connection has been terminating every 24 hours, necessitating manual re-authentication by an administrator with appropriate credentials.

It is worth noting that:

  1. No configuration changes were made to either FieldPulse or QuickBooks Online prior to this behavior commencing
  2. The disconnection occurs consistently at approximately 4:00 PM UTC daily
  3. Our API usage has remained within documented rate limits
  4. Refresh token rotation appears to be failing silently — no error notifications are generated

I have confirmed that our QuickBooks Online subscription is active and that third-party app permissions remain granted. The re-authentication flow completes successfully each time, suggesting the OAuth consent is not being revoked at the source.

Is this a known issue with the QuickBooks integration connector? We are evaluating whether to implement a manual token refresh workflow via API, but this would introduce operational overhead we had not anticipated.

Our current environment: FieldPulse 3.3.1, QuickBooks Online Plus, SSO not enabled for the integration account.

Parents
  • Hi Fatima — in my experience, this pattern typically points to a mismatch between how FieldPulse is requesting token refresh and a recent change on Intuit's side regarding refresh token lifetimes. What I typically recommend is verifying a few specific items before assuming it's a bug on either platform.

    QuickBooks Online made a change in early 2024 that reduced refresh token validity for certain connection types when the app is in 'development' mode versus 'production' mode. However, that shouldn't apply to established FieldPulse connections. More likely, what we're seeing here is that the token refresh is happening at the 24-hour mark, but something in the token storage is not persisting the new refresh token that's returned with the access token.

    Here's what I would check:

    First, look at whether your integration was originally set up under a different QuickBooks user account that may have since been deactivated or had its permissions modified. The FieldPulse integration stores credentials against the specific QBO user who authorized it, not just the company. If that user leaves or their role changes, the refresh can fail even though the initial connection test passes.

    Second, there's a known interaction between certain firewall configurations and the token endpoint that can cause the response containing the new refresh token to be dropped. This is rare but I've seen it twice in enterprise environments with strict outbound filtering.

    Third, and this is the most common cause in my experience, QuickBooks Online will invalidate refresh tokens if the same user authorizes the app multiple times across different browsers or devices. The most recent authorization wins, and previous refresh tokens become invalid. If someone on your team has been testing or re-authenticating, that would explain the 24-hour cycle.

    What I typically recommend as a next step: disconnect the integration entirely from FieldPulse, then revoke the app authorization from within QuickBooks Online (Settings > Apps > FieldPulse > Disconnect), wait approximately 10 minutes, and reconnect using a dedicated service account rather than a personal user account. This ensures no other sessions can interfere with the token lifecycle.

    From a governance perspective, this also aligns better with audit requirements since the service account can be configured with minimal permissions and monitored separately.

Reply
  • Hi Fatima — in my experience, this pattern typically points to a mismatch between how FieldPulse is requesting token refresh and a recent change on Intuit's side regarding refresh token lifetimes. What I typically recommend is verifying a few specific items before assuming it's a bug on either platform.

    QuickBooks Online made a change in early 2024 that reduced refresh token validity for certain connection types when the app is in 'development' mode versus 'production' mode. However, that shouldn't apply to established FieldPulse connections. More likely, what we're seeing here is that the token refresh is happening at the 24-hour mark, but something in the token storage is not persisting the new refresh token that's returned with the access token.

    Here's what I would check:

    First, look at whether your integration was originally set up under a different QuickBooks user account that may have since been deactivated or had its permissions modified. The FieldPulse integration stores credentials against the specific QBO user who authorized it, not just the company. If that user leaves or their role changes, the refresh can fail even though the initial connection test passes.

    Second, there's a known interaction between certain firewall configurations and the token endpoint that can cause the response containing the new refresh token to be dropped. This is rare but I've seen it twice in enterprise environments with strict outbound filtering.

    Third, and this is the most common cause in my experience, QuickBooks Online will invalidate refresh tokens if the same user authorizes the app multiple times across different browsers or devices. The most recent authorization wins, and previous refresh tokens become invalid. If someone on your team has been testing or re-authenticating, that would explain the 24-hour cycle.

    What I typically recommend as a next step: disconnect the integration entirely from FieldPulse, then revoke the app authorization from within QuickBooks Online (Settings > Apps > FieldPulse > Disconnect), wait approximately 10 minutes, and reconnect using a dedicated service account rather than a personal user account. This ensures no other sessions can interfere with the token lifecycle.

    From a governance perspective, this also aligns better with audit requirements since the service account can be configured with minimal permissions and monitored separately.

Children
No Data