How do you refresh OAuth tokens from the credentials feature outside of an automation block?

Just to add a running commentary to this, I opened a support ticket – #4919458 – and got the following response today:

Regarding the new apps framework infrastructure, the managed credentials feature is designed to deliver OAuth tokens strictly at runtime within the payload of execution blocks (such as actions or triggers). Currently, there is no native mechanism to programmatically pull or request these managed credentials from an isolated background context like a monday-code cron job.

To achieve your goal of renewing Microsoft Graph webhooks every 3 days via a scheduler, we recommend managing the token lifecycle manually within your background process. You can utilize monday-code Secure Storage to securely persist and handle your own OAuth tokens. Here is the approach:

1. When your integration block executes and receives the initial accessToken and refreshToken, securely store them and their expiry timestamps.
2. Structure your cron job endpoint to retrieve these tokens from Secure Storage, check the expiration, and programmatically call the Microsoft Graph refresh endpoint directly to handle the renewal.

This is the exact solution I used in the old automations infrastructure, when I had to do the token refresh myself and store it in SecureStorage.

The new workflow based infrastructure extracts that away and monday takes care of the access and refresh token.

I now do not have any eyes on the refresh token because monday never supplies me with that information.

The automation body is in the following format:

{
  "payload": {
    "blockKind": "action",
    "credentialsValues": {
      "microsoftToken": {
        "userCredentialsId": 37300,
        "accessToken": "...",
        "userCredentialsParams": {},
        "tokenRequestedParams": {}
      }
    },
    ...  
  },
  ...
}

As you can see, the refresh token and expiry are never received by the automation block, even after reauthenticating with the external system in the workflow/automation block.

So I cannot do this myself as monday does not allow it. 

It would be great to know how monday achieves this, say for incoming Outlook emails using the workflow based infrastructure? 

They must be doing something similar to keep the "email received" webhook alive for the built in automation blocks.

The saga continues.

For those people who are following along, here’s another update from support (from May 28, 2026).

I’ve emboldened the most interesting parts:

Thank you for providing that payload example. You are entirely correct, and I see exactly where the roadblock is now.
 
Because the new workflow-based infrastructure completely abstracts the OAuth lifecycle, stripping out the refreshToken and expiry metadata from the payload is an intentional security design choice on monday's side. However, your point is completely valid: since you do not have visibility into the refresh token, the traditional workaround of manually managing the rotation inside SecureStorageis impossible.
 
This highlights a genuine architectural gap in the new framework regarding background processes, like your monday-code cron job, that need to handle third-party webhooks with strict expiration timelines (such as Microsoft's 3-day window).
 
[...]
 
Please hold off on changes while I take this specific payload limitation to our Managed Credentials and Workflow Infrastructure engineering teams to see how they intend for third-party developers to keep background subscriptions alive without refresh token access.
 
I will keep you updated as soon as I have more concrete information or an internal workaround from the team.  [...]

I’ll try to continue updating this thread as and when I have fresh information.

Hello ​@dvdsmpsn. I am facing the exact same issue with my application and I have also a respective ticket about it. Did you find a way forward?

​@Kenotom dev That’s simple - It seems that you cannot do this. It’s a limitation of the credentials feature. And it’s a massive problem that has not been addressed yet.

For those people who are following along, here’s another update from support (July 16, 2026).

To be fully open with you: as of today, there is no new technical update from our developers since our last discussion, but I can tell you exactly where it is sitting.
 
This is not lost in a generic support queue or waiting in a static backlog. Because your case highlighted a foundational architectural limitation, where the new workflow framework completely strips the refresh token, leaving no public or internal API endpoint for a monday-codecron job to request an update via the userCredentialsId, it was escalated directly to the Workflow Infrastructure and Managed Credentials core engineering teams.
 
Right now, it is an active engineering discussion topic rather than a simple bug fix. The team is reviewing this as a structural framework limitation for third-party developers building background synchronizations. I am checking our internal ticket and the engineering sync channels daily to see if they will prioritize creating a platform-level background refresh endpoint, or if they can provide an unreleased infrastructure workaround specifically for your app ID.
 
I know your integration is completely paused until we have a path forward on this, and I hate leaving you in a holding pattern. I promise that the moment the infrastructure engineers provide a definitive direction, a potential alpha endpoint to test, or an architectural decision, I will update you immediately.