Do you have any advice for handling 50+ webhooks? I need to watch section changes and new tasks in every project in our workspace, so I was forced to create a webhook for every single project in the workspace. Now I have 50+ webhooks, but they all send health checks at almost the same time of day and overwhelm my little server. (This would not be an issue if we could create a webhook which watches a team/workspace for task updates).
All I want is to watch all new tasks and section changes in the workspace, which I’m doing anyway—but I’m forced to do so by having a ton of separate webhooks for the different projects.
Is there any way to at least stagger the webhook health checks?
Also, I noticed that one of my webhooks failed a couple of health checks but was still “Active”. However, it stopped sending notifications for events until I deleted it and created it again. Is there a way to be notified when a webhook stops sending updates because of failed health checks? This silent failure behavior is very difficult to deal with.
Hi @Giovanni_Segar,
Are you using filtering on your webhooks? That won’t get you less webhooks or less heartbeat (health check) messages, so it might not help in your case, but it would reduce the number of actual webhook events you get and have to process.
There’s no way to tell Asana when you want to receive the heartbeat messages. I haven’t tested it myself but if you stagger the creation of webhooks, that might stagger the heartbeats?
There’s no way to be notified when a webhook becomes deactivated. That would be great if there were. OTOH, the only way a webhook knows of communicating is with its target endpoint, so if it concludes the target endpoint is dead, it has no place to send such a notification.
Final suggestion (ok, you had to know this one was coming):
Get a bigger server.
Yes, I filtered down to section changes and task additions. I have thought of staggering the creation for heartbeats, just haven’t gotten around to it.
Fair enough RE: the server 
Just think that it’s very simple for Asana to allow subscriptions to low-level events at a higher point in the hierarchy and let people decide for themselves how to use that.
It’s not a question of simplicity but of volume. Events go into queues where they’re then disbursed via webhooks, and Asana devs are concerned about the potentially enormous volume of data that would have to be processed and disbursed in a queue and webhook. Don’t forget that whatever they do has to work up to their large Enterprise customers, who can have hundreds or thousands of teams and projects, and tens or hundreds of thousands of tasks in a workspace.