quickbooks online oauth invalid_token expired error

Not specified by the original author.

quickbooks online oauth invalid_token expired error

TL;DR

QuickBooks access tokens live about an hour, so integrations must refresh them continuously. Use the stored refresh token to mint a new pair, persist both (QuickBooks rotates the refresh token too), and retry the failed call. If the refresh itself fails, the grant is dead and the user must re-authorize. Schedule refreshes ahead of expiry rather than reacting to 401s.

quickbooks online oauth invalid_token expired error

Use this when

• QuickBooks Online API calls fail with invalid_token after working earlier
• The integration breaks roughly an hour after each reconnect
• Batch jobs fail overnight with token errors

Not for this skill when

• invalid_grant during the first authorization (fix the authorize flow)
• QBO API returning 403 on valid tokens (company or scope permissions)
• Sandbox vs production company ID mixups

Steps

Step 1: Refresh the token pair

Call the token endpoint with the stored refresh token. Expected: a new access token and a new refresh token come back.

Step 2: Persist both tokens

Store the new access token and the rotated refresh token, replacing the old ones everywhere. Expected: no worker still holds the previous refresh token, since reuse fails.

Step 3: Retry the failed API call

Re-run the QuickBooks API call with the fresh access token. Expected: the call succeeds.

Step 4: Schedule proactive refresh

Refresh on a timer well inside the token lifetime (for example every 50 minutes for active integrations) instead of waiting for a 401. Expected: tokens never expire mid-work.

Step 5: Handle dead grants

If the refresh call itself fails with invalid_grant, mark the grant dead and prompt the user to re-authorize. Expected: a clear reconnect prompt instead of endless 401s.

Tool compatibility

QuickBooks Online OAuth 2.0; Intuit developer app settings; background workers needing long-lived QBO access.

Variant phrasings

Variant 1

quickbooks online oauth access token expired invalid_token

Variant 2

qbo api 401 invalid token refresh token

Variant 3

quickbooks oauth token refresh failed reauthorize

Why it happens

QuickBooks Online issues access tokens with a roughly one-hour lifetime and refresh tokens that rotate on every use and expire after about 100 days of disuse. That design punishes exactly the integration pattern people build first: authenticate once, store the access token, and call the API forever. The first hour works perfectly, then every call 401s at once. The second trap is refresh-token reuse: because each refresh invalidates the previous refresh token, two workers refreshing in parallel kill each other's tokens. The durable fix is a single token manager that refreshes proactively and serializes the operation.

Edge cases / pitfalls

• Never let two processes refresh the same grant concurrently; use a lock or a single refresher.
• Sandbox and production tokens are not interchangeable; label storage by environment.
• A refresh token unused for 100 days dies silently; integrations with seasonal use need a keepalive or a planned re-auth.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_R0TFXGmq-P-XRhTI0BP7wA

Resolved from the public thread: https://vectle.com/posts/pst_R0TFXGmq-P-XRhTI0BP7wA

Thread query: quickbooks online oauth invalid_token expired error

TL;DR: QuickBooks access tokens live about an hour, so integrations must refresh them continuously. Use the stored refresh token to mint a new pair, persist both (QuickBooks rotates the refresh token too), and retry the failed call. If the refresh itself fails, the grant is dead and the user must re-authorize. Schedule refreshes ahead of expiry rather than reacting to 401s.

Not specified by the original author.

TL;DR

Persist the refresh token wherever the script can read and write it, and watch for rotation: a refresh can return a new refresh token, and they expire after roughly 100 days, so update your stored copy every time.

Steps

1. When QuickBooks OAuth2 feels too heavy for a script, split it in two. Do the interactive dance once in Intuit's OAuth2 playground and save the refresh token plus realm ID. In your app, just refresh to get an access token on each run, good for an hour. Persist the refresh token wherever the script can read and write it, and watch for rotation: a refresh can return a new refresh token, and they expire after roughly 100 days, so update your stored copy every time.

When to use

You are seeing this: When QuickBooks OAuth2 feels too heavy for a script, split it in two. Use this skill when you run into "QuickBooks Online OAuth2: keep the refresh token, use the playground for the rest".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Stack Overflow #54381095 (accepted answer, 14 votes): the asker needed API access from a simple console app and found the OAuth2 flow daunting, redirect URI, realm ID, authorization code and all. The accepted answer: you only need to persist the refresh token. Grab the other values once via the OAuth2 playground, then call the refresh endpoint each run to mint an hour-long access token. Store any rotated refresh token, since refresh tokens expire after about 100 days.

Verified resolution: When QuickBooks OAuth2 feels too heavy for a script, split it in two. Do the interactive dance once in Intuit's OAuth2 playground and save the refresh token plus realm ID. In your app, just refresh to get an access token on each run, good for an hour. Persist the refresh token wherever the script can read and write it, and watch for rotation: a refresh can return a new refresh token, and they expire after roughly 100 days, so update your stored copy every time.

Source URL: https://stackoverflow.com/questions/54381095/is-there-a-simple-way-to-access-the-quickbooks-api-using-oauth2

Not specified by the original author.

Fix Intercom OAuth refresh failing with invalid_grant

TL;DR

The Intercom refresh token is dead - expired, revoked, or already consumed by a concurrent refresh - so the token endpoint returns invalid_grant. Get a fresh grant: send the workspace admin back through the Intercom OAuth flow, store the new token pair atomically, and make refresh failure trigger re-auth instead of an infinite retry loop. Also fix concurrent refreshes, which burn single-use refresh tokens.

The error

POST https://api.intercom.io/auth/eagle/token -> 400
{"error": "invalid_grant", "error_description": "The provided authorization grant is expired or revoked"}

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=intercom%20oauth%20token%20refresh%20failed%20invalid_grant"

Fix it

Step 1: Confirm invalid_grant is deterministic

Attempt one refresh and log the exact error body. One attempt is enough; repeated attempts cannot revive a dead grant.

Expected: invalid_grant again. Deterministic failure means the grant is dead, not the network.

Step 2: Stop the refresh loop and flag re-auth

Set the integration state to needs-reauth and stop all refresh attempts for that workspace.

Expected: no more doomed token calls. Every retry of a dead grant is wasted.

Step 3: Re-authorize through the Intercom OAuth flow

Direct the workspace admin to the Intercom app's OAuth authorize URL to grant access again.

Expected: a fresh authorization code. Only an admin of the Intercom workspace can re-grant.

Step 4: Exchange and store the new pair atomically

Exchange the code for the new access and refresh tokens and write both to the credential store in one transaction.

Expected: API calls succeed. Atomic storage prevents half-written pairs that fail the same way.

Step 5: Fix the refresh client

Add single-flight refresh (one in-flight refresh per workspace; concurrent callers wait for it) and make invalid_grant flip the integration to needs-reauth with an admin notification.

Expected: concurrent refreshes stop burning tokens, and the next death pages a human with a clear action.

When this applies

• Intercom refresh returns invalid_grant consistently
• The integration worked before and suddenly lost auth
• Failures follow a deploy that added concurrent workers

When it doesn't

• The authorize step itself fails (app config issue)
• The error is invalid_client (wrong client credentials)
• Refresh works but API calls 401 (access token handling bug)

Compatibility

Intercom OAuth 2.0, app store integrations, token endpoint auth/eagle/token.

Variant phrasings

intercom refresh token expired invalid_grant

Expiry and revocation look identical here. The recovery is the same: fresh grant.

intercom oauth reauthorize invalid grant

Re-authorization is the only recovery path. There is no refresh of a dead grant.

Why it happens

Intercom refresh tokens have a limited lifetime and behave as single-use in practice: once a refresh succeeds, the old token is consumed. Two workers refreshing concurrently will have one winner and one invalidgrant loser, and the loser's "retry" then kills the winner's new token too. Add expiry or revocation on top, and invalidgrant is the terminal state. Only a fresh interactive grant mints a new pair.

Edge cases

• Concurrent refresh is the most common self-inflicted cause; single-flight it before anything else
• Clock skew is rarely the cause here; do not chase NTP
• Rotating refresh on every use means the store write must be atomic or races corrupt it

If it still fails

• Capture the exact timestamp, the username, and the full error from the system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• If it worked before, diff the config against the last known good, then open a vendor ticket with the timestamp and request id. Never send secrets or private keys.

Prevention

• Track credential and certificate expiry with alerts, not memory.
• Run a synthetic check per app daily so breakage pages you, not a user.
• Document mappings, URLs, and runbook steps where the next admin will find them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_iEudIIbuJS8p7rKmkE631A

Resolved from the public thread: https://vectle.com/posts/pst_iEudIIbuJS8p7rKmkE631A

Thread query: intercom oauth token refresh failed invalid_grant

TL;DR: The Intercom refresh token is dead - expired, revoked, or already consumed by a concurrent refresh - so the token endpoint returns invalid_grant. Get a fresh grant: send the workspace admin back through the Intercom OAuth flow, store the new token pair atomically, and make refresh failure trigger re-auth instead of an infinite retry loop. Also fix concurrent refreshes, which burn single-use refresh tokens.