Can't Create Organizational-level Webhook

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. :slight_smile:

Oh! I did end up adding a section at the end of the webhooks description https://developers.asana.com/docs/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.

1 Like

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)

That being said, @Guinness_Chen, I can think of 2 approaches here:

  1. Multiple webhooks (sorry for the overhead). One on the workspace to see projects being added, and one on each project.
  2. Multi-homed tasks. You could multihome all tasks into a private project. You then have a single webhook on that project.

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. :frowning:

@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:

  • Webhook events from tasks, subtasks, and stories won’t be propagated to these higher-level webhooks, so all changes on these resources are automatically filtered out.
  • Webhook events from project resources can be filtered for these actions: added, removed, deleted, undeleted, and changed.
  • Webhook events from team_membership resources can be filtered to actions added and removed.
  • Webhook events from workspace_membership resources can be filtered to added and removed.

@Ross_Grambo,

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:
image

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.

1 Like

That would be awesome! If you publish it, I and probably others can happily point out anything we might find missing from it. :slight_smile:

1 Like