Hi All,
We're running an HTTP Universal Connector integration against an internal (homegrown) REST API, authenticated via OAuth 2.0 Client Credentials. We've been intermittently seeing 401 Unauthorized errors and after digging into the trace logs, we've identified a pattern we want to validate with the community before we finalize our remediation approach.
What the traces show:
We're seeing two requests fired in quick succession on failure:
- First request (e.g. trace c967a41c) → rejected with a 401 in ~597µs, token expired 11 days prior
- Second request (e.g. trace c967a41d) → succeeds in ~241ms with a freshly obtained token
We also identified a separate failed request (trace c967a163) where the cached token had a different expiry date — only ~10 days earlier than the first — despite both requests occurring within 9 minutes of each other. This suggests Celigo may be holding multiple stale tokens across different cached sessions.
Our interpretation:
Since Celigo uses a reactive refresh strategy — sending the cached token, waiting for a 401, then fetching a new token and retrying. While the retry succeeds, the initial 401 is causing noise in our error monitoring and we'd prefer proactive refresh.
What we've tried so far:
We've reviewed the connection settings and confirmed there's no exposed "token expiry offset" or "expiry path" field in our current connector UI. We're also verifying that our token endpoint returns a proper expires_in value in the response.
Questions for the community:
- Has anyone successfully configured proactive token refresh with the HTTP Universal Connector on Client Credentials? If so, was it a UI setting or did you handle it via a pre-request hook?
- Is the reactive retry-on-401 behavior expected/by design in Celigo, and is there a known way to override it?
- Has anyone used a JavaScript pre-request hook to manually check token expiry before each call?
Any insight from those who've navigated this would be greatly appreciated. Happy to share more trace details if useful.