Seeking feedback on apps webhooks - help shape the future!

[gregra (Greg Rashkevitch)]

Hey developers!

My name is Greg and I’m leading the app framework here in monday

As part of our ongoing efforts to enhance the monday platform and provide developers with the tools they need, we’re reaching out to you, our valued community members, for your insights and feedback.

Why webhooks matter?
Webhooks are a crucial component for many apps, enabling real-time communication and integration between monday and external systems. We want to ensure that our webhook offerings align with your needs and expectations.

Why your input matters?
We believe that the best way to improve our webhook capabilities is by understanding your specific requirements and use cases. Your feedback will directly influence our upcoming roadmap, ensuring that we prioritize the features and enhancements that matter most to you.

What we need from you?

• Share your experiences: Tell us about your experiences with monday webhooks. What’s working well, and what could be improved?
• Use cases: describe the specific use cases where you rely on webhooks. How do they fit into your workflows?
• Wishlist: are there any features or enhancements you’d like to see in our webhooks? Any pain points that need addressing?
• Integration challenges: Have you faced any challenges when integrating monday with other systems via webhooks? We want to hear about them.

How to share your feedback?
Please reply to this post with your feedback, questions, or suggestions. Feel free to be as detailed as possible, as your input is incredibly valuable to us.

What’s next?
We’ll be actively monitoring this thread and engaging in discussions with you. Your feedback will help shape our plans for improving our webhooks.

[kranthi_thoughtflow (Kranthi Kiran)]

Hey @gregra

Webhooks are great, but in the app sdk, these should be a last resort. If some thing is technically possible without a webhook, the api should provide this functionality.

A webhook comes with the additional cost of

• An additional language for the backend
• Hosting and maintaining a server/service
• Making sure that the server is secure and meets the standards for enterprise data
• Additional effort while getting our apps approved by the marketplace team

Here’s an example of a use case - Listening to changes in item title and updating in our app UI . I think this should have been a straightforward use case for the monday.listen API instead of having to create a Webhook.

On a side note, it would be great if monday could provide us some way to create serverless API endpoints without having to host our own server

Hop this helps . Thank you.

[basdebruin]

hi @gregra

Nice to e-meet you here. We at Excellent Team have 15+ apps on the marketplace and almost all of them are creating webhooks through the API. All these apps are integrations and we do have some issues with webhooks in this specific environment.

One of the reasons our customers contact us is because they do wee different webhooks belonging to the app. It is a real improvement that you now see which webhooks belongs to which app :). The webhooks are created in the subscribe event and the configuration of the integration recipe is stored in a loacl database (with the webhookId). In the unsubscribe event we are removing the webhook based on the webhookId we hold in the database. Although the webhooks are really deleted they still show up on the board. Most time they disappear after a page refresh (but not always). It would be great if you could delete the visual appearance of the deleted webhooks from integrations page.

In many cases we need to add different webhooks (e.g. item created, column changed, item deleted). In the endpoint receiving the webhooks events we need to distinguish between items created and column changed because an item created with values (like an Excel import or Forms submission) does NOT trigger the column changed webhook. Technically I do understand the difference, but our mutual customers do not understand that creating an item through the UI and then change a column is technically different from creating an item with those column values.

It would be awesome if we would have a “custom webhook” that is NOT available in the standard automations (only when creating them through the API) that accepts a more complex configuration, like fire if column A, B or C is changed AND when item is created / moved to this board / deleted / archived / moved away from this board). I would love to have such “custom webhook” that can be configured to combine all kind of events and would NOT be visible in the integrations page.

Always open to discuss further.

[codyfrisch (Cody)]

• Allow us to specify an integration ID for which a webhook is being created, and to update this in the future (such as if we get an unsubscribe/resubscribe from a custom trigger, or handle it automatically for us)
• With the specification of the integration ID, nest/fold associated webhooks with the recipe - so the customer can see the associated webhooks but keep them hidden normally to make their workflow pages less cluttered.
• Auto-delete the webhooks attached to an integration ID when the integration is deleted to ensure customer boards stay clean.
• when a custom trigger is updated/removed send us the list of attached webhook IDs.
• Send us notification of a webhook removal via webhook to the webhook URL or another URL we can specify.
• Allow us to specify the webhook data structure for the webhook output. Specifically trigger.outputFields where we can add keys such as itemId and specify what value they should contain from the webhook trigger such as pulseId. We can then specify the custom trigger URL as the webhook URL (with the custom trigger URL supporting the challenge). This would have to include the client secret automatically by virtue of the app creating it, and being attached to an automation ID from the app. (or some implicit authentication mechanism by virtue of being with the platform)

All of the above adds up to letting us attach as many triggers as we need directly to a recipe, eliminating the need for us to forward payloads to triggers - or even necessarily manage the webhook lifecycle after creating them

[TomFri (Tom Fridman)]

Thank you for putting effort and share the feedback with us @codyfrisch @basdebruin @kranthi_thoughtflow

[dvdsmpsn (David @ David Simpson Apps)]

Hi @gregra

I’m quite happy with webhooks for the moment.

One thing that I notice, and it’s very minor, is consistency…

This real world example contains both "nil" and null:

{
	"type": "app_subscription_cancelled",
	"data": {
		...
		"subscription": {
			"plan_id": "...",
			"renewal_date": "nil",
			"is_trial": false,
			"billing_period": "monthly",
			"days_left": null,
			"pricing_version": 1
		},
		...
	}
}

I’m guessing that both of these mean the same thing.

[rachel.miner]

Hi! I’m part of a product data team that consumes the data generated from webhooks. During our dev process, we’ve run in to a couple of challenges so far:

1. We’d like more documentation about what values should be expected for all text based fields. We’re consumers of the data and in charge of data governance. So we want to ensure that we understand what is expected so we can properly handle misconfigured/missing data.
2. The ability to test all/more webhooks prior to launching an app on the marketplace, specifically the license webhooks. We found that prior to release we’re only able to generate test webhooks for the uninstall/install events but none of the other license events. It would be helpful to know prior to release that these webhooks have been configured properly on our side.

Happy to discuss further if that would be helpful. Please feel free to reach out.

[Matias.Monday (Matias)]

Thank you everyone for your feedback!

It will be reviewed by our team

[MHaigh (Matthew Haigh)]

Hi
We have different levels of people with different needs, and depending on the use case, and experience of the team can drastically alter the demands…

1. Low-Code connection (Zapier/Make) etc
2. Programmers/Developers using API for specific workflows/integrations
3. Developers create tools for use within Monday
4. Enterprise requirement for integration with data warehousing.

Webhooks are great for 1-2. Would be really beneficial if we can trigger webhooks from custom automations rather than the limited set of options in the integration… this would really open up our integration capability.
For 1-3, would be great if there was an advanced options on the webhook to allow customising the headers, this would help add security options etc.
For 2-3 agree with other comments re ability to get direct in API.
For 4 would be great to have some specific options to allow data to be sync’d to data warehouse (snowflake etc) - we have serious issues with the rate limits and size through the standard API to do this, so having a dedicated channel to allow enterprise organisations to have tables regularly pushed out would really help with some of our larger clients.

[Matias.Monday (Matias)]

Thank you for sharing your thoughts @MHaigh !

[Nir-Jetpack (Nir @ Jetpack Team)]

+1000 for Auto-delete the webhooks attached to an integration ID when the integration is deleted to ensure customer boards stay clean by @codyfrisch this is becoming a burning issue now - we are deleting webhooks from the backend for customers on daily basis.

[Matias.Monday (Matias)]

Thank you @Nir-Jetpack for sharing!

[gregra (Greg Rashkevitch)]

Everyone, thank you very much for that feedback, super helpful! I’ll try to address / clarify some of the issues brought up.

@kranthi_thoughtflow I hear you loud and clear about the extra work required to work with webhooks, but these are the advantages:

1. You get live data from us, i.e. changes are reflected immediately in your app. The other alternative will be to poll for all boards data all the time and I don’t think it’s practical
2. As monday platform grows (larger boards) and developer platform grows (more API consumers) our API won’t be able to meet the potential scale of endless polling from every possible API consumer, just to get the up to date data from every board

Regarding your use case - this can definitely become a candidate for the roadmap.

Regarding your side note, I don’t know if you’ve heard but we’re starting to roll out to beta our new native app hosting project called “monday code”, you can sign up here in case you’re interested

@basdebruin thank you for this feedback, I’ll try to address your points one by one:

1. For the unsubscribe event, it can take up to a few minutes (at most) until the webhooks are cleared from the board as the process is asynchronous on our side, but we’ll definitely consider if (and how) we can approach this
2. Can you be more specific on the challenge here? Is it because the customer sees multiple webhooks on the board? Is it because you want to do only one api request to register your webhook?
3. Heard load and clear. This is a great feedback and we’re definitely considering this approach in our future roadmaps

@codyfrisch thank you for this list, we’ll consider how and when we can include these improvements and changes in our roadmap.

@dvdsmpsn thanks you for that feedback, and I’m happy you find our webhooks useful.
Regarding null VS nil, I’ll add this to our backlog

@rachel.miner first of all, welcome to the community! I hope you’ll find it valuable and helpful
Regarding your feedback - heard you loud and clear on both points, we’ll see how and when we can incorporate these into our roadmap.

@MHaigh regarding webhooks limitation to the set of integration options - got it. Regarding customizing headers for the requests - got it. On 4 - this is a bit off topic for webhooks but I can definitely understand the motivation behind this request

@Nir-Jetpack heard you load and clear

[MHaigh (Matthew Haigh)]

Thanks for the update and for listening.

Not sure if this is directly on webhooks (more about the api and User tables) but would be really useful if the API can be extended to enable adding/removing users to/from teams and being able to update the “user” custom fields and having custom fields set as admin access only - we want to minimise client admin so need to sync user details (employee id, office location, job title etc) in but have to do this to a separate “Employee” table that we keep in sync with Monday and another couple of systems. The webhooks are great to tell us about activity but the API doesn’t allow us to update the Teams (ie new user we use the AD job title/office synced in to Monday to select certain steams the user should be member of, so they automatically get the correct access. Would be great to be able to updates team membership and be able to store additional user data in the user tables but have it locked so only admin/automations can update.

[basdebruin]

hi @gregra

Thank you for your feedback. The “challenge” of having multiple webhooks from the same app (like column change, item created, item deleted) is that the end-user gets confused as they don’t understand what each webhook exactly does. From a coding perspective it doesn’t really matter although a single call to create a “multi-functional” webhook would be nice. It ties back to the next point form my original reply to have a custom webhook that is configurable for multiple event types.

[kranthi_thoughtflow (Kranthi Kiran)]

Thanks for the thoughtful response @gregra . I’ve avoided webhooks so far, but now I can think of some areas in our app where we could enhance the user experience by leveraging webhooks. I’ve signed up for the “monday code” project. Looking forward.