The /v2/oauth/token endpoint returns invalid_grant immediately after the initial access token expires.
We are deploying a Premium App across three organizations using the multi-org OAuth flow. The refresh token appears valid in the logs, but the platform rejects it upon rotation. The integration uses the Node.js SDK v2.4.1. This behavior started after the recent security patch. The client credentials are correct, and the redirect URI matches the AppFoundry configuration exactly. Any insights on token scope limitations in multi-org contexts?
The simplest way to resolve this is to ensure the grant_type is explicitly set to refresh_token in the body, a step often overlooked when porting over from Zendesk’s simpler OAuth flows.
{
"grant_type": "refresh_token",
"refresh_token": "your_valid_refresh_token_here"
}
Have you tried verifying that the refresh token rotation is not triggering a silent failure in the multi-org context? The suggestion above regarding the grant_type is technically correct for standard OAuth, but in a multi-org deployment with AppFoundry, there is a significant risk of token scope leakage.
When handling legal discovery or bulk recording exports, we often see this exact invalid_grant error when the refresh token is issued against a different organization ID than the one making the API call. The Node.js SDK v2.4.1 handles single-org tokens well, but it does not automatically switch the organization context during the token exchange. If the initial access token was granted for Org A, but the background job is running under Org B’s context, the platform will reject the refresh token because it does not match the target organization’s security policy.
Check the organization_id parameter in your token request body. It must explicitly match the organization where the recording data resides. Here is the corrected payload structure:
{
"grant_type": "refresh_token",
"refresh_token": "your_valid_refresh_token_here",
"organization_id": "target_org_uuid_here"
}
Additionally, ensure that the API user associated with the app has the Recording:Read and Organization:Read permissions in all three organizations. A common oversight is granting permissions in the primary org but forgetting the secondary ones. If the token is refreshed without the correct org context, the subsequent calls to /v2/recordings will fail with 401 or 403, breaking the chain of custody for legal holds.
Also, verify that the refresh token itself has not been rotated manually or revoked by a security audit in one of the orgs. In our experience with EU regions, strict compliance policies sometimes auto-revoke tokens if the IP address changes during the refresh window. Check the audit logs for “Token Revoked” events.