Refresh Token not working. 401 Unauthorized

I have resurrected an application to access ESI data and while the OAuth flow to get the access token works as expected I have found that the refresh flow is not.
When the access token expires the Okhttp interceptor kick in and starts the refresh flow.
I have followed the Refreshing tokens documentation and used the properly received refresh token I got from the initial login to test the /v2/oauth/token endpoint with Postman.
Every time I get a 401 Unauthorized.
The response I get is this:
Date: Fri, 05 Jul 2024 09:41:50 GMT

Transfer-Encoding: chunked

Connection: keep-alive

request-context: appId=cid-v1:2ccf88f2-29b9-460a-bc15-7c0b79926f61

set-cookie: lang=en; expires=Sat, 05 Jul 2025 09:41:50 GMT; path=/; secure; samesite=lax; httponly

content-security-policy: default-src ‘self’; base-uri ‘self’; object-src ‘self’; img-src ‘self’ https: data: blob: filesystem:; font-src ‘self’; style-src ‘self’ ‘unsafe-inline’; script-src ‘self’ ‘nonce-t787K4hPZEGAR+L/qXHjiA==’ ‘report-sample’ ‘strict-dynamic’ ; connect-src ‘self’; frame-ancestors; frame-src; report-uri Report URI: Website security, made easy.

x-powered-by: ASP.NET

strict-transport-security: max-age=31536000; includeSubDomains; preload

CF-Cache-Status: DYNAMIC

Set-Cookie: __cf_bm=Nt2hM7vLrBoR_SHgDo0B3V3GomJrNNfeCkBxaXTyxRY-1720172510-; path=/; expires=Fri, 05-Jul-24 10:11:50 GMT;; HttpOnly; Secure; SameSite=None

nel: {“report_to”:“ccp”}

report-to: {“group”:“ccp”,“max_age”:31536000,“endpoints”:[{“url”:“Report URI: Website security, made easy.”:true}

Server: cloudflare

CF-RAY: 89e666cb5a3a2168-MAD

alt-svc: h3=“:443”; ma=86400

I have checked that the User agent does not contain Java and that the request contents follows the documentation specs.
curl --location --request POST ‘’ \

–header ‘Content-Type: application/x-www-form-urlencoded’ \

–header ‘Host:’ \

–header ‘Cookie: __cf_bm=Nt2hM7vLrBoR_SHgDo0B3V3GomJrNNfeCkBxaXTyxRY-1720172510-; lang=en’

I need advice how to solve this.
Thank you.

401 Unauthorized is a strong indicator that the Authorization header is wrong. If your request was broken, you’d see a 400 Bad Request, and if the system would accept your Authorization header but not allow you to do a certain action, you’d probably see a 403 Forbidden.

I would recommend double and triple-checking the Authorization header, maybe logging it somewhere, and trying to reconstruct the esi client id and secret from the base64 encoded header.