Hi,
I tried to setup a Webhook to listen to task completions at the organizational level, but I was returned status 403. The error was
`“invalid_filters_for_larger_scoped_webhooks”
and the message was
“Webhooks for larger scoped resources must have at least one filter and all filters must be in our whitelist.”
I tried filtering the events to only receive “marked_complete” and “marked_incomplete”, but I was returned the same error.
How can I resolve this error?
Hi @Guinness_Chen,
Please post the exact content of your webhook request so we can see where it’s off.
Here’s the request body:
{
"data": {
"filters": [
{
"action": "added",
"resource_subtype": "marked_complete",
"resource_type": "story"
},
{
"action": "added",
"resource_subtype": "marked_incomplete",
"resource_type": "story"
}
],
"resource": "9811672847608",
"target": "https://xxxxxxxxxxxxx"
}
}
Hi @Guinness_Chen,
You’re not able to filter at the story level for a workspace-scoped webhook.
As it says in the API docs:
To reduce the volume of data to transfer, webhooks created on teams, portfolios, and workspaces must specify filters. In addition, the set of event filters that can be placed on a team-level or workspace-level webhook is more limited than filters for webhooks that are created on lower-level resources
However, the documentation does not spell out exactly what that means (it’s on their list to add this info to the docs - hint hint @Ross_Grambo).
To my knowledge, this is the whitelist from which filters need to be specified for webhooks above the project level:
"resource_type": "workspace_membership", "action": "added""resource_type": "workspace_membership", "action": "removed""resource_type": "team_membership", "action": "added""resource_type": "team_membership", "action": "removed""resource_type": "team", "action": "added""resource_type": "team", "action": "deleted""resource_type": "team", "action": "changed""resource_type": "project", "action": "added""resource_type": "project", "action": "removed""resource_type": "project", "action": "deleted""resource_type": "project", "action": "undeleted""resource_type": "project", "action": "changed"I’m not 100% sure that’s a complete, accurate list, but it’s close. 
Oh! I did end up adding a section at the end of the webhooks description Webhooks. I poked through the code and grabbed all the events I could find. It looks like I missed workspace membership though, so I’ll add that!
Hey @Ross_Grambo,
I did see that list. What’s missing is a specification showing at which target-resource levels each of those webhook filters is valid. For example, from that list there’s no way that @Guinness_Chen can tell that you can’t specify a story level filter at the workspace target-resource level.
Oh I misread the previous message. Yes, you’re absolutely right. I don’t even know what that list is. There is a task sitting around about it, but I’ll ping it again.
Talking with an API eng, they said the whitelist for Workspace is exclusively:
That being said, @Guinness_Chen, I can think of 2 approaches here:
I’d recommend the second approach because it sounds the cleanest (Even though you’ll need rules to multihome).
Projects are the highest leveled container that we propagate Task events to, so you’re stuck using events on the Project level. 
@Phil_Seeman, my coworker Matt said that this info should have been in the docs already, and idk how I didn’t see it, but he’s right! It’s in the webhooks section right above Error Handling and Retry. It says:
To reduce the volume of data to transfer, webhooks created on teams, portfolios, and workspaces must specify filters. In addition, the set of event filters that can be placed on a team-level or workspace-level webhook is more limited than filters for webhooks that are created on lower-level resources:
I’ve seen that also but I respectfully submit that’s still not nearly enough info. Just to take the example from this thread, where in that text does it tell us that you can’t request a story filter on a workspace-level webhook and that the webhook creation will fail with an error if you try?
I still submit that what’s needed is a table like this:
Note to all: the above is NOT nearly a complete table - it’s just an example of how I envision it could look to provide comprehensive info on what webhooks and actions are available at each target-resource level.
That’s a fair point. It states that the events don’t propagate up to that level, but it doesn’t state that your webhook post request will fail if you try anyway.
There is no concise list in the code for me to build a comprehensive list… I think it’s still worth us making this table even if it’s not fully comprehensive. Thanks Phil, I’ll take note of this.
That would be awesome! If you publish it, I and probably others can happily point out anything we might find missing from it.
Hello,
I agree with @Phil_Seeman .
That would be awesome to have a list of filters available for each target resource.
I tried this morning to set a webhook to get notified when teams are changing.
To do that, I tried to create a webhook on the target resource workspace with filters being on the resource team with actions added / changed / removed.
But it failed with the error message
Webhooks for larger scoped resources must have at least one filter and all filters must be in our whitelist
which means that the filters aren’t in the whitelist for the target resource workspace.
However, I didn’t find in the documentation where it was clearly stated that this kind of webhooks wouldn’t work.
Hi @Martin21,
I haven’t tried to filter on team but I was under the impression that was a valid filter. @Ross_Grambo would you be able to check on that? Thanks!!
That’s what I thought too.
But after reading this thread, I am no longer sure about it.
This is what @Ross_Grambo said earlier in this thread:
Talking with an API eng, they said the whitelist for Workspace is exclusively:
WorkspaceMembership (added|removed)
TeamMembership (added|removed)
Project (added|removed|deleted|undeleted|changed)
Oh oops, I guess next time I need to review the whole thread before replying!
The list I posted, which included team, did come directly from a former API engineer (who’s no longer with Asana), so I’m a bit surprised that team filtering is not available. OTOH, I trust @Ross_Grambo and his info is more current than mine.
It appears teams is not a valid webhook filter yet.
I put in a request for it to be added. Until then, you’re stuck polling for changes.