Skip to main content

Hi fellow developers


I am trying to get my head around this.


I need to query all items and subitems in a given board. Due to the amount of items and the level of nesting the query will hit complexity very soon. I want to use pagination to query in smaller pieces but I have to wait for the next minute (reset of complexity) and I am using shortLivedTokens to access the API. If I just wait for 1 minute the shortLivedToken will not be valid anymore.


At this moment the query takes place during the subscribe of an integration app with a custom trigger. I don’t see a way to “refresh” the short lived token as I can’t respond with non-200 (no retries will be done from monday). I can redesign in a way the query takes place in an action so I can respond with non-200 and wait for the retry (which will contain a new shortLivedToken). The challenge with that is to keep track of which page is required.


Any ideas are welcome.

Concerning the page number, why don’t you keep track of that and then after one minute you request for more data with an increase in page number, since you will be supplying the page number as an argument any way.

Sure I can keep track of the page number but I might be a little harder than that. I can’t save it within the action endpoint and return a non-200 to get a retry. And when I do not return the shortLivedToken will be invalid after the 1 minute wait.

Hi @basdebruin!


Have you considered issuing a permanent token (using OAuth), storing it and using it for this long process? Would this be a possibility?


Looking forward to hearing from you 🙂


Cheers,

Matias

hi @Matias.Monday


I fully understand that this can be solved using permanent (stored) tokens. To be honest I hate storing tokens and I hope our customers hate it as much as I do. ShortLivedTokens is a great way to improve privacy and I love to use them. I would consider using OAuth tokens is they had a more granular scope (like board). In the current state a customer needs to give full access (all boards) to the developer and I would never do that if I was the customer.


In my opinion monday.com needs to rethink this and support pagination in combination with shortLivedTokens. A possible implementation might be that the app does respond like “return res.status(206).json({page: 1});” and that monday sends that JSON in the payload of the retry post (with a new token). In that way the app could retrieve the next page and this continues until the app responds with 200.


I believe the underlying issue is that monday has implemented just one reaction on non 200 responses and that is “retry the same thing”.


Another solution would be that the app can store an app specific JSON to the board where the app could keep track on the pagination page number.

Hello @basdebruin,


Matias here!


I hear what you say about the shortlived tokens and adding support for pagination in combination with them sounds very interesting :🤔


I will share this input with our team so that it can be reviewed 🙂

Reply


Terms & ConditionsCookie settings