I am trying to use webhooks to set up notifications for my app. I then check to make sure the webhook’s type is story, if it is I do a client.stories.findById(resourceID) to get the full story. However, sometimes it seems like it cannot find the story using my resourceID. I noticed that it happens mostly with stories associated with tasks that I have deleted. Could it be because the task was deleted and therefore the story is no longer there?
Another follow up question: When subscribing to webhooks, is it ok to ignore type ‘task’ and type ‘project’ and only check webhooks with type ‘story’. It seems like the webhooks labeled ‘task’ are redundant since every change comes with a ‘story’ webhook anyways. Is this a correct assumption?
Hi @Will_Lerner, are you un-completing these stories within 24 hours of having completed them? The Asana product has a concept of “story consolidation” where certain actions will cause new stories to interact with old stories, sometimes resulting in the new story getting deleted. In this case, if you mark a story incomplete and create a marked_incomplete story, after a few moments that story might “consolidate” itself with the previous marked_complete story. Both would get deleted, so trying to fetch the new story would result in the error you’re seeing.
Thanks for the detailed response Joe! It seems like the only safe way to get the actual completed state of the task related to the story is by fetching the task directly.
Is it even worth it to try to fetch stories that are included in the webhook event if many of them will produce 404’s? We could fallback to fetching the task in the case of a 404 I guess?
Most “story added” webhooks don’t result in story deletions—it depends on the kind of story (comment added, name changed, added to project, etc.), who created the story, and when the last story of the same type was made. If you only care about the current state of the task, the most robust solution would be to fetch the task directly. If you want some information from the story too, you could fallback to fetching the task if the story was deleted. If you want to avoid the second round-trip to the API in the fallback case, you could use the batch API to fetch both the task and the story at the same time, and use whatever data comes back successfully.