Having trouble using monday.setToken within the Apps SDK

Hi all

I am starting to use the SDK to develop apps with dashboard features. I am just building some proof of concept simple apps at the moment, to test API queries.

I am able to upload an app as a dashboard feature, query data using the sdk and render it, which is great. I am taking advantage of seamless auth provided by the monday.api() method.

I now would like to start developing more efficiently, so i am trying to pass a token with the queries, so that i can debug in my local environment (rather than having to build and upload every time). I have tried using monday.setToken(‘api_token_provided_in_the_admin_section_of_monday.com’)

and i have also tried passing the same within the options parameter of the monday.api method.

when running locally, the api returns the error saying i am not authenticated (as if i had passed an incorrect token or no token at all).

I triple checked the token i am passing. I am using the same in a raw query using Postman and that returns the data i expect.

Help would be most appreciated, let me know if you need more information on the issue.


Hey @jaacquees.
Can you share further details and some pieces of code?

hey @jaacquees – you also mentioned you want to develop your client-side apps more efficiently. I would recommend using ngrok for local development, because it streamlines the workflow. That way you don’t have to rely on a build-upload process each time, but can still use seamless authentication and see your results in monday.com.

Essentially, you run ngrok http [port] and the tool will generate a URL that you can put in the “view setup” testing section of your app feature.

You can install it globally or run it from inside our starter code (it’s bundled as a dev dependency).

Check out our quickstart video (around 2:40) to see it in action: https://monday.com/developers/apps/quickstart-view

Many thanks Dipro. I managed to create the tunnel and hook up the embedded app to my debugger (using webstorm right now). Breakpoints work, which is great.

Thanks again!

thanks Rob. I’ll just go with dipro’s suggestion for now, but i am interested in resolving the issue about setToken:

async getAllBoardNames():Promise<MondayItem>{
var result = await this.monday.api(
query{ boards{ id name } },{token:this.tkn}

  return result.data.boards as Board[];


it doesn’t work and result is just {errors:[“Not Authenticated”]}

Hey, I am facing the same problem.
I used my api key in https://monday.com/developers/v2/try-it-yourself and it’s working great.
But plugging it into my ngrok development and viewing it live in widget setup preview and using
monday.api(query/mutation, {token: apikey})…
Neither work and I get the message: error: Not Authenticated

Leaving out the token info doesn’t work either, but am I misunderstanding the documentation when it says “If not set, will use the credentials of the current user (client only)”. Should it work anyway?

As an update on this:

When I write a simple standalone app using the mondaySdk, use setStoken to give it my personal API token (which has full access to all boards), API calls via the Sdk work as expected - I can get data fine.

However, when I run an app from within a monday parent app, pass the API token via setToken, and query the api via the Sdk method, the response suggests that the API token I have given is « hidden » by whatever access token is present in the parent session: for instance, if the parent session has a viewer or a guest logged in, the Sdk call to the api will not return any data (even if the Sdk has received an all powerful access token via setToken).

The use case for me right now, is that I am trying to find a way to get data into a board view app even when a guest or a viewer is logged in.

Hey @jaacquees,

Is this issue only occurring when you try to do with a guest or viewer account? I say this because I believe setToken can only be used server side, and all monday.api calls from the client side will use the logged in user’s token. This could be why this is occurring with guest/viewer accounts.

If you would like to use a single token for all API requests, you’ll need to make the API calls from your backend (or make HTTP requests without the SDK).


Yes this is exactly the issue.

As a workaround I am trying to expose an end point on my own API which calls monday API v2 to get the required data for my app.

It works fine when I call my API on localhost. But for some strange reason, when I deploy it to my remote server, that endpoint can’t be reached by the app. I can reach it fine using postman, but the JavaScript app can’t reach it. It’s all very confusing.

If anyone has managed to make a board view or dashboard widget, which calls the API for data, without using the session’s token or the Monday.api Sdk method, please let me know !



Hey @jaacquees,

Are you getting some kind of error? If so could you post it (or a screenshot of what’s going on)?


I was up until 3am trying to “catch” a verbose error message, but all i got was http request failure - unknown error…

It’s such a weird one, it may be some sort of glitch or limitation of our hosting server.

I am going to try apollo to send a graphql query directly to the v2 API.


Just so I am clear, you are trying to use the setToken method from a monday.com view/widget application?

Or are you trying to use setToken running on your own server? I.e an integration recipe?

You don’t need to use setToken if you are using a view/widget feature as the SDK will automatically collect the sessionToken of the logged in user.

Hi Mitchell.


Yes I am aware of seamless authentication which avoids using setToken. It is a great feature which I am using currently. The problem is that, when a guest/viewer is logged in, seamless authentication will pick up their session token and try to use it to access the Monday API, which will fail and produce an error.

I was trying to use setToken to “override” seamless authentication and give the app a token which will allow it to use the API. But that doesn’t work. setToken is basically not made for a client-side context.


Thanks @jaacquees, I understand now.

You are correct, setToken is not made for client-side. It is a server-side feature.

As Daniel pointed out, you don’t really have any option here unless you make a request to your server.

So basically, instead of using the SDK to make a call, you will need to make a call to your server application and use a stored API token to make the request, then return the result back to your view.

It isn’t an idle solution but it will get around your viewer/guest access token issue (as long as it is authorized by another user). This could also cause some security issues with viewers and guests seeing data that they are not meant to.

1 Like

Hey @jaacquees,

Please see Mitchell’s post above regarding the API call. Let me know if you have any other questions!


Thanks Mitchell. You summarised the issue quite well.

I have used the following workaround: use mondaySdk as normal (to listen for context and settings changes) except that I don’t make API calls using monday.api, but using apollo.query, a common graphql library.

Indeed it is not ideal, because I am having to give the app a full member’s token explicitly (the guest user token would not work).

The mitigation is that we are very very selective with our guests and viewers and are comfortable that there will not be any misuse or misappropriation of the token.

Having said that, it would be a lot better if there was a way for it to work natively, i.e. make board contents available as part of the apps context. That way it would only expose what each user is allowed to see, and tokens would be kept safe.

Again @monDevs I can’t stress this enough. The Monday UX/UI is so vibrant and beautiful, it is a waste to not share it with clients and other partners. But to make their experience complete, these users must have a way to see custom developed views and widgets.

Thanks all

1 Like

@jaacquees We hear you loud and clear, and we appreciate the kind words on the UI/UX. I’ll be sure to pass on both pieces of feedback internally to the team and hopefully it’s something we can tackle in the near future.