Quick question about the token refresh mechanism for secondary organizations. The initial authorization code grant succeeds for the primary tenant, but the subsequent POST to /oauth/token for the secondary org returns a 401 Unauthorized with an invalid_grant error. The refresh token appears valid in the developer console, yet the API rejects it immediately upon rotation.
The problem is likely that a mismatch between the client_id used for the initial grant and the one registered for the secondary org’s AppFoundry app.
Verify the client_id in your POST payload matches the secondary org’s specific application settings, not the primary tenant’s.
To fix this easily, this is to ensure the client_id and client_secret in your POST payload match the specific AppFoundry application registered for the secondary organization, not the primary tenant. While the suggestion above correctly identifies the mismatch, it is worth noting that the refresh token itself is also tied to the specific client ID. If you generated the initial grant using the primary tenant’s credentials, the resulting refresh_token is invalid for the secondary org’s scope. You must re-initiate the authorization code grant flow using the secondary org’s distinct client_id. This ensures the issued tokens are scoped correctly for that specific tenant environment. In our weekly scheduling workflows, we see similar scope errors when API calls attempt to cross tenant boundaries without re-authenticating against the target org’s specific application settings. Double-check the grant_type is set to refresh_token and verify the redirect_uri matches exactly what is configured in the secondary org’s AppFoundry settings.
I’d recommend looking at at this section on how refresh tokens are bound to specific client IDs. If the initial grant used the primary tenant’s credentials, the token is invalid for the secondary org regardless of the payload.