I’m new to Monday.com and have developed an app that interacts with a third-party API whenever the status changes on a Monday.com board. The app is ready for production, but I’m unsure how to handle the Access Token.
I plan to add more features soon and would like to begin the review process for the Monday marketplace. For users to use my app, an access token must be provided. However, the third-party API I’m using doesn’t support OAuth2; instead, users must generate a secret key from the API and provide it to my app.
If what you need is for the users to be able to provide you with a token so that your app with an integration feature can use it, you might want to use the Authorization URL as explained here.
It will give you the opportunity to show a screen in which you can prompt the user to provide you with credentials from the other platform
That sounds exactly like what I need—thank you for the response!
I’m wondering if it’s the responsibility of my app to store the user token and extract it with every trigger? If so, what’s the recommended approach for saving it when using Monday’s code?
It is in deed something that you need to do on your end securely. Tokens must be encrypted. If your app is meant for the marketplace, the review team will ask you to provide supporting evidence and describe how the app stores tokens and to elaborate on what security controls are used to protect the monday.com user access token.
@dvdsmpsn@Oded282 correct me if I’m wrong, your use cases is users provide their tokens; if so, CLI feels unnatural.
Isn’t secure storage the go-to in those cases?
My use case is that a shared OAuth ID+secret for an external system is used in the app by every account and user, so can be set once at deploy time. Secrets is the way to go in this instance.
If you need to save secrets for individual users, SecureStorage is probably the way to go.
@Oded282 I’d also look into the “credentials” field in recipes (its a new thing). It lets you collect a credential while the recipe is being setup - then the users can pick it in the future. It still redirects you for entry.
This method has the advantage in that the redirect only happens if the user choses to add a new credential. If they pick an existing one, then there is no redirect.
The redirect to the authorization URL takes 10-20 seconds total every time a recipe is added, if the credential is being reused, then the credentials field lets them pick it repeatedly without a redirect (and back) that takes time. This can reduce abandonment of your app in trial/demo phase.
The credential field should store a reference to your encrypted token (a key to look it up from secure storage). I don’t believe storing the encrypted token in the response you give the field is wise (though I haven’t seen any guidance from monday either way)
First, thanks for your response! I’ll dive deeper into it, as it definitely seems like it would create a better user experience.
Secondly, I’ve been reflecting on the authentication process for a Monday board when triggered by a third-party webhook.
Let me explain.
Let’s say the user has already provided their third-party credentials in some way and completed the recipe setup. When the user makes a change to their board, the app’s route is triggered, sending a request to the third party using the provided credentials. The API works, and a successful integration with the third party is established. Now, suppose the app has exposed another route that waits for a process from the third party to complete, which could take a few days. Once the third party finishes this process, it triggers the relevant route in the app, and this route is supposed to update a column on the Monday board.
My question is: How can a route triggered by the third party update Monday board values? What authentication process should be in place to grant that access? Since the token can’t be sent in the query as it was when the initial recipe was triggered, how would the app authenticate?
I hope my question is clear, and thanks in advance!
You can pass a payload to them, along with your monday signing secret. It will then pass the payload to all of the actions in the automation. Those actions generate a short lived token, and send it to your backend to do the update with.
Actually, I’m referring to other use case of a recipe trigger. In this case, the route will be triggered by a third-party, so I assume I won’t be able to obtain a shortLivedToken, correct?
I’ve deployed Monday’s “Hello World” GitHub example for Monday apps. From what I understand, this example uses OAuth2 during the app installation process and saves a token in secure storage for the user ID. Later, when the third-party webhook is triggered, that token can be used to access the user’s board.
I don’t have much experience with OAuth2, but I think I can try to replicate this process for my use case. What do you think?
Your route triggered by the third party, itself then triggers a monday.com integration trigger - that trigger then sends an action back to another route in your backend, which does the actual work.
So there is a trip through the monday infrastructure in the middle that results in you getting a token.
3rd party => your route => monday trigger => monday action => your route2 (with token)
The user creates the second recipe on the board, not you.
The second recipe is “when process is completed… do something (status change, etc.)”.
If the trigger is able to be published for custom use, this lets your users integrate other workflow steps into the external process being completed for example. Otherwise you can provide a few prebuilt recipes.
One thing to avoid is locking users into preconceived workflow expectations - because they will always want to do things you didn’t expect, its just how the user base is.
While it seems more complicated - asking the user to create the second recipe - what you’re doing is giving the user control over how their boards behave, and their business process instead of dictating it to them.
Yes you’ll probably want to create a short guide, or video for release.
