An integration can connect successfully to UPS API, then begin returning authorisation errors. An expired token is one possible cause. Obtaining a token does not make access permanent.
Where is the lifetime specified?
The official UPS OAuth Client Credentials specification includes expires_in in the response. It describes the requested token’s lifetime in seconds. Read the server’s value rather than replacing it with a fixed duration chosen earlier.
What should the integration check?
The specification defines expires_in as a string. Convert it to a number when calculating expiry and use seconds. Store the lifetime alongside the token.
A practical approach is to obtain a new token before expiry, leaving a small margin for the request. This is an integration recommendation, not an additional deadline imposed by UPS. If several processes run together, check that each is not requesting a new token unnecessarily.
For an authorisation error, identify the cause first: expiry is not the only possibility. Avoid endless identical retries and do not write tokens or client secrets to ordinary logs.
Who needs this check?
Developers of shops, delivery services and other systems using UPS API directly. A sender booking through a ready-made platform does not need to obtain an OAuth token personally.
Use a test integration to check token acquisition, reuse and expiry handling. An example in documentation is not a promise of a permanently fixed access lifetime.
Frequently asked questions
Can one fixed lifetime be used for every token?
Do not replace the server’s response with a constant. Use the expires_in value for the token received.
What units does expires_in use?
Seconds. The UPS specification defines the field as a string, so convert it to a number for calculations.
Does an ordinary sender need to obtain a token?
No, if they use a ready-made shipping platform. This configuration is for developers of systems using UPS API directly.
