hi there,
I am new to Monday.com and have developed a Web Hook to perform some tasks when an item is added to a Monday.com board. The web hook is ready for production, but I am not sure what to do in terms of the Access Token.
What is the best practice approach?
For example, using my personal Access Token does not appear to be a sound idea.
If the web hook is productionised with my personal access token and I leave the the company and my account is disabled won’t that disable the Web Hook too?
The documentation seems to suggest that there are only personal access tokens, which seems a little off to me - I am sure that I am missing something!
Anyway, thanks a million for your help in advance,
Kevin
hi there,
Is there a better place to ask this question within the community?
thanks,
Kevin
You’re in the “using apps and integrations” section, monday Apps & Developers - monday Community Forum is the development of them.
That said, there are a couple options - one is use a “Service account” which is another monday account that lives on past your employment. This has the added benefit that you can use it to build all your board automations and workflows - and they will also live on past your personal account.
The other option, and more complex, is the actual apps framework. You can create recipes there that send a short lived token with them, so you don’t even need to store a token. However the app framework does lack a number of the webhook triggers and the payloads are different so you’d incur redevelopment time to adjust your code to a different structure (and potentially needing to fetch some data that isn’t in the webhook sent).
The missing triggers can be overcome though, by creating custom triggers and your code then creates webhook and you handle those, to then trigger the custom trigger. Its a bit of a pain though.
The custom triggers though have other advantages - if you have a backend system (like some custom business solution) you can trigger changes on monday with them. The column ids and board ids then don’t have to be baked into your code.
IN summary, you have the easy solution which just requires paying for another account and having a succession plan for it. Or a more complex using the apps framework - but also much more flexible and capable in some respects.
Thats another point often not considered, if your user gets disabled all of your automations will too. There are tools to transfer automations to new owners. Integrations can somewhat be transferred but you have to manually visit each one on every board and reactivate them. Plus your replacement owner would then need to be made an owner on all of the boards too (there are tools built in for this).
The service account at least eliminates the need for transitioning anything except access to the service account.
1 Like