401 Unauthorized immediately after token refresh - clock skew issue?

Hit a wall with our custom OAuth token management script. We’re using the standard two-legged auth flow to pull data for a custom reporting tool. Everything works fine for the first hour, but the moment the access token expires and the script attempts to refresh it, the subsequent API calls fail with a 401 Unauthorized.

The refresh itself seems to succeed. I’m seeing a valid new access token in the response payload. But when I immediately use that new token to hit /api/v2/users/me, it bombs.

Here’s the sequence:

  1. Get 401 on initial call.
  2. Call POST /api/v2/oauth/token with grant_type=refresh_token.
  3. Receive 200 OK with new access_token and refresh_token.
  4. Immediately call GET /api/v2/users/me with the new access_token in the Authorization header.
  5. Get 401 Unauthorized.

The error message is generic: {“status”: 401, “code”: “unauthorized”, “message”: “Unauthorized”}.

I’ve been staring at the code for an hour. The token string looks correct. The header is set as Bearer .

Thinking it might be a clock skew issue between our server and the Genesys auth server. Our server time is synced via NTP, but maybe there’s a drift? Or maybe the token isn’t valid yet?

Does the token have a small delay before it’s active? Or is the refresh token being invalidated too early?

I’ve tried adding a 5-second sleep between the refresh and the next call, but it still fails.

Any ideas? Is there a way to check the exact expiration time of the token in the response? Or a way to force a re-auth?

Here’s the refresh call :

POST /api/v2/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token={refresh_token}&client_id={client_id}

The response has:

{
 "access_token": "eyJ...",
 "token_type": "Bearer",
 "expires_in": 3600,
 "refresh_token": "new_refresh..."
}

Stuck on this. Help appreciated.