shortLivedToken is expired during a long process

hi @stavYaarBar
Welcome back 🙂. Can you explain a little more what you are doing? Which side (monday or your app) is doing the scheduling? Ig it is monday your app will be triggered and in each call from monday there is a shortLivedToken. As the name suggest, this is short lived - I believe it is valid for 30 seconds and only within the agreed scope of the app.
If you want a token that does not expire you have to get one through the OAuth flow and store that token safely in a database.

Does that make sense?

hello @basdebruin and thank you for the reply and the nice welcome 🙂

what you said make sense, but im still missing something.

i think i have a workaround solution to my problem, but still have some questions that maybe you can help me with them,

monday is doing the scheduling, im using the “Every time period” trigger on monday in my recipe to trigger my backend once a month. theres no UI in the process, is there a way to get the token in another when fully automated like that? i cant do a handshake because theres no active action from the user at any point.

i would like to know for future use, if im doing a monday integration and the shortLivedtToken is expired, is there any way to renew it? some kind of refresh token? or a different way to get a long use token without a handshake that require the user to actively approve my request everytime?

also, i there a chance that i get a new req from monday integration because my token was expired in the first place? it feels like it might be the case, my token was my process is still going, but the token was expired and monday got no response back, so they send a new req automatically?

again, thank you very much! i really appreciate this

hi @stavYaarBar

Let me try to answer to the best of my knowledge.

Every request you get from monday (e.g. to your action endpoint) holds that shortLivedToken. There is no way to renew or extend the lifetime of that token. However, if you respond with a non 200 code (e.g. return res.status(429).send({})😉 monday will retry with a fresh token. That is probably what you see. If you are not able to do all the work in those 30 seconds 😦 I think you should consider getting a permanent token through OAuth.

To do this, you need to configure the callback endpoint in your app.

When the user adds the app to the account the OAuth handshake will start by calling the configured endpoint. A good reference is https://apps.developer.monday.com/docs/oauth

Hey hey @stavYaarBar and @basdebruin :wae

Great discussion here! Thanks so much for shedding more light on this @basdebruin.

I do want to clarify a bit and confirm that the shortLivedToken is valid for 1 minute! Just wanted to be as precise as possible here, as it could be helpful to other developers. Otherwise, I also confirm that the shortLivedToken is generated when the trigger runs. In your case, when the scheduled trigger runs once a month, you will get a token that you could use to make API calls for 1 minute.

As mentioned in our [Choosing an Authentication Method(https://apps.developer.monday.com/docs/choosing-auth) article, it does sound like your app would be much better suited to use an OAuth token instead.

What do you think? Let us know 🙂

-Alex

Thank you @AlexSavchuk and thank you @basdebruin !

i understand now theres no work around the short live token in this case.
i took your advices and im using an OAuth token instead.
the app im building is just for one account so my one time workaround was to build a new app that has only one button that takes to the monday authentication window, and an end point to give to monday for the callback function. ive deploy the app, than send it to my client, once he entered and approved everything i got the token in my callback function and saved it to my data base.

it feels a little messy and makes me thing that im still missing something. for example, what if my app is general and not only for one client that i can send him a link and have him do the handshake manually?

there’s also a possibility that im asking too much 🙂

@AlexSavchuk i also want to add that when printing the time difference using “jwtRes.exp” that i got
with the shortLivedToken it shows 300s === 5 min. if the expiration is after 1 minute than what’s that time stamp means?

and again. thanks for the help 🙂

hi @stavYaarBar

I would not use an OAuth token from one app in another app as the scope of the app might be different. I would build the OAuth flow in the original app and store that token in a database (securely 🙂). When your app is used by multiple clients you should store the token in a database with the accountId.

@stavYaarBar

I agree with what @basdebruin is saying here! Instead of using 2 apps to really do the work of 1 app, why not implement the OAuth flow inside your original app instead? The user will be directed to the OAuth flow every time they try to create your app’s recipe. Your app’s Auth URL could also be used in order to check if the user creating the recipe has already gone through the OAuth process.

In that case, you should allow the user to pick an existing connection, instead of asking them to go through the flow again and again.

I’ve just tested the shortLivedToken generated by an app, and it did expire within a minute. Not quite sure what might be causing the discrepancy here.

I hope this helps!

-Alex

@AlexSavchuk , @basdebruin
here’s a funny thing, i had no idea about the authorization checkbox inside the integration… ive made dozens of integration by now and somehow was able to miss it… everything is clicking now…
also now i see why creating a different app sounds so bizzare 🙂
i was missing the fact you can redirect the user when they install my apps recipe…

so to get this straight, i can redirect the user to my backend when they create a recipe, then i can redirect them again to my app OAuth authorization url, then they being redirected back to my callback url and then i can finally get the permanent token and redirect them the to backToUrl i got from the first request? or something like that… of course with more logic to see if they already exist or not.

anyway i think i finally got it,
i learned a lot from both you so THANK you so much… everything is clear now

@stavYaarBar

OH, amazing! I’m glad we were able to clarify and I’m happy to hear you’ve found yet another useful feature in the framework 🙂

In terms of the flow, I suppose you could put it this way:

• The Admin of the account installs the app first, and from there, users are able to add recipes to their boards, or widgets to their items/boards/dashboards;
• Then, when a user tries to create a recipe in your app, they will be sent to your app’s Auth URL.
• From there, you could ask the user to authorize the app and send them to your app’s OAuth URL, or, if your app’s database already has the token, they can use an existing connection;
• At that point, if the user approves your request, your app will redirect the user to one of the redirect_uris specified.
• Finally, your app will receive a temporary authorization code, which you can exchange for the long-term API token.

Either way, it seems like you are well on your way here!

-Alex

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.