Token management for Rest Integration

[madhuv]

Hi Team ,

Need some inputs from you on Token Management.

We have some integrations where token URLs have been explicitly called to obtain tokens and obtained tokens will be passed to the actual intended Rest calls to perform the required operation with third party tools.

Since these calls are frequent, we have been warned from third party systems that we are obtaining tokens very frequently (like 1 min ) whereas the token validity is 30 mins.

So, we are planning to obtain the token through scheduled job that will run every 25 mins and thinking to store the token in 'Oauth Credentials' table (oauth_credential) which opens when Manage Tokens is clicked in Filter Navigator. Then re-use it for our regular calls.

My question is , can we use this table to manage the token like this? 

I know when we have the Application Registry setup with Ouath profile along with connection credentials , system will refresh the token automatically before the call made. But we don't have the set up like that, also, in this setup as well system frequently refreshes the token OTB way and this frequency is not intended for us too.

Please help us with your valuable inputs..

[Ravi Gaurav]

Hi @madhuv 

Read the below info this will help .. I tweaked it Accordingly:

You are currently generating a new token for every REST call (every 1 min), while the token is valid for 30 minutes. The third-party system flagged this because of excessive token requests.

You are considering running a Scheduled Job every 25 minutes to fetch a new token and store it in the oauth_credential table.

 

Can you use the oauth_credential table?

Not recommended.

• This table is reserved for ServiceNow’s internal OAuth mechanism (Application Registry + OAuth Profiles).

• Writing directly into it may break built-in functionality and cause unexpected behavior.

 

 Recommended Approaches

1. Custom Token Table + Scheduled Job (Best for your scenario)

• Create a custom table, e.g., u_integration_tokens.

• Fields: access_token, expiry_time, source_system.

• Build a Scheduled Job that runs every 25 minutes:

  • Calls the token endpoint.

  • Saves the new token and expiry in the table.

• For each integration REST call:

  • Read the latest token from this table.

  • Use it in the Authorization header.

 This ensures tokens are reused until expiry.

 

 Application Registry + OAuth Profile (Long-term Best Practice)

• Create an Application Registry in ServiceNow with the OAuth profile.

• Link this profile to your REST Message.

• ServiceNow automatically refreshes the token only when needed (before expiry).

• This avoids unnecessary token calls.

 

Example Flow (Custom Table Method)

Scheduled Job Script (fetch token):

var r = new sn_ws.RESTMessageV2('Token Request', 'post'); var response = r.execute(); var body = response.getBody(); var parsed = JSON.parse(body); if (parsed.access_token) { var gr = new GlideRecord('u_integration_tokens'); gr.initialize(); gr.u_token = parsed.access_token; gr.u_expiry = gs.minutesAgo(-30); // or parse expires_in if provided gr.insert(); }

Integration Script (use token):

var tokenGR = new GlideRecord('u_integration_tokens'); tokenGR.orderByDesc('sys_created_on'); tokenGR.setLimit(1); tokenGR.query(); if (tokenGR.next()) { request.setRequestHeader("Authorization", "Bearer " + tokenGR.u_token); }

 Final Recommendation

• Do not use oauth_credential directly.

• Use a custom table with scheduled refresh for short-term.

• Move to Application Registry with OAuth profile for a robust long-term solution.

[M Iftikhar]

@madhuv ,

In one of my earlier projects, we had a similar scenario where the token validity was only 10 minutes. Within that timeframe, we had to make multiple calls in a loop, with the token passed as a header. To handle this efficiently, we designed a flow where:

• The token was passed through the flow for all calls. (Scripted Rest Steps via custom action; one for getting token other for actual rest call)

• We added a condition to check if a request failed due to “token expired.” (We received error when token is invalid - aka expired so based on that we use to run the custom action again to get a new token, also saving this token as flow variable to pass on to the 2nd custom action as header.) 

• This way, we weren’t calling the token endpoint unnecessarily; instead, we only refreshed the token when it was truly expired. This approach helped avoid excessive token requests and ensured smooth integration.

Thanks & Regards,
Muhammad Iftikhar

If my response helped, please mark it as the accepted solution so others can benefit as well.