Expired Wolfram Cloud API tokens return 401 without automatic refresh

Short answer

There is no documented configuration or header that makes URLFetch, HTTPRequest/URLRead, or the HTTPClient functions renew an expired Wolfram Cloud scoped token automatically. An expired bearer token is surfaced to your code as an ordinary HTTP authorization failure — typically 401, occasionally 403 depending on the endpoint — and the request simply fails. The recommended pattern is a small wrapper that detects the authorization failure, obtains a fresh token through your normal credential flow, and retries once.

Why this is the likely explanation

Scoped API tokens are stateless bearer credentials: the server validates whatever token you present at request time. There is nothing in the request itself that can ask the server to extend an old token, so renewal has to be client-driven. This is the standard behavior for bearer-token APIs generally, and it matches what you are observing. Treat the "is there a hidden auto-refresh?" question as answered: assume there is none until Wolfram documents otherwise.

Detecting expiry

Two complementary strategies:

• Proactive: when you create the token, capture the expiry/TTL returned by the creation call and store it alongside the token. Do not assume the 24-hour default — it is configurable. Refresh shortly before the stored expiry. This avoids a failed first attempt in scheduled jobs.
• Reactive fallback: inspect the response status code (and body, since some endpoints return useful error detail) on every call. On 401, refresh and retry. Note that a 403 may mean insufficient scope rather than expiry, so after refreshing, re-check that your scopes actually cover the operation before retrying blindly.

The wrapper

Yes — wrapping the request is the right approach. A minimal sketch:

cloudCall[req_HTTPRequest] := Module[{resp, token},
  token = getValidToken[];  (* returns cached token, refreshing if near expiry *)
  resp = URLRead[HTTPRequest[req, <|"Headers" -> {"Authorization" -> "Bearer " <> token}|>]];
  If[resp["StatusCode"] === 401,
    invalidateCachedToken[];
    token = getValidToken[];  (* force refresh *)
    resp = URLRead[HTTPRequest[req, <|"Headers" -> {"Authorization" -> "Bearer " <> token}|>]];
  ];
  resp]

Key rules for the wrapper:

• Retry exactly once after a refresh. A second 401 means something else is wrong (scopes, revoked credentials) — looping will hammer the token endpoint, which may be rate-limited.
• Serialize refreshes. If multiple scheduled tasks hit expiry simultaneously, use a lock or single-flight mechanism so one task renews and the others reuse the new token. Otherwise you get a refresh storm.
• Check idempotency before retrying writes. Retrying a read after refresh is safe. Retrying a write can duplicate effects if the original request actually reached the server before failing. Use idempotency keys or server-side deduplication for non-idempotent endpoints.
• Never log tokens. Redact the Authorization header from any diagnostic output, CloudObject metadata, or notebook cells.

Verifying the behavior

Before committing to this design, confirm it against your actual deployment:

1. Create a short-lived scoped test token, wait for expiry, and call a protected cloud object. Record the exact status code and body — this tells you whether your endpoints return 401, 403, or both.
2. Run the same call through the wrapper and confirm the retry succeeds with a fresh token.
3. Simulate two scheduled jobs expiring at the same time and verify only one refresh occurs.

One caveat: exact error codes and token-creation response fields can vary between Wolfram Cloud versions and endpoint types, so treat step 1 as authoritative for your environment rather than any general description — including this one.