Problem creating a webhook

Creating a webhook with this posted data:

{

“data”: {
“filters”: [
{
“resource_type”: “task”,
“resource_subtype”: “default_task”,
“action”: “changed”,
“fields”: [
“Assignee”
]
}
],
“resource”: “1183597376574265”,
“target”: “https://my.domain.com/webhook_receive.php
}
}

I have tried custom field ‘Cleaning Status’ and ‘Priority’ and what i think is a standard asana field ‘assignee’ (how do i get a list of valid fields btw??)

i get this error message:

{

"errors": [

    {

        "error": "invalid_filters_for_larger_scoped_webhooks",

        "message": "Webhooks for larger scoped resources must have at least one filter and all filters must be in our whitelist.",

        "user_message": "Webhooks for larger scoped resources must have at least one filter and all filters must be in our whitelist.",

        "help": "For more information on API status codes and how to handle them, read the docs on errors: https://developers.asana.com/docs/errors"

    }

]

}

i figured this one out. i replaced the resource (my organization) with a board gid and created my first webhook, then figured out how to delete it so i could try again.

HOWEVER, it won’t let me create a webhook with fields
“fields”: [
“Cleaning%20Status”,
“Assignee”,
“Date%20Due”
]
}
tried with the %20 or the space.

i am getting:
{
“errors”: [
{
“error”: “invalid_webhook_filter_fields_format”,
“message”: “The fields field must be non-empty list of non-empty strings containing only letters and underscores.”,
“user_message”: “The fields field must be non-empty list of non-empty strings containing only letters and underscores.”,
“help”: “For more information on API status codes and how to handle them, read the docs on errors: Errors
}
]
}

1 Like

(sorry, haven’t figured out how to use the markup on this board to format this stuff. nor how to edit a post i’ve created to try to clean it up).

I’m not sure that these fields are correct. I suggest grabbing the event data on its entirety first. Take a look at the fields you are getting in the event object before filtering. Alternatively you can take a look the events schema here: Events

1 Like

And to larger scope resources you need to add a some filter so start only with resource_type and action :slight_smile:

“filters”: [
{
“resource_type”: “task”,
“action”: “changed”, 
}

then if you want you can experiment with fields as proposed above.

1 Like

for anyone else reading this, you need to put a _ in for any spaces in a column name. so “Cleaning Status” (confirmed on the event log, thanks for that tip) needs to be “Cleaning_Status” or you get the error.

the other field (a std asana field, not a custom field) on here that is titled “Date Due” on the UI is actually due_date when i look it up on the event log, so changing that one was necessary too.

but problem solved, i can create webhooks that reference the correct std and custom field names now.

2 Likes

another update.

even though cleaning_status will set a hook, it’s actually not doing anything… you can set a hook on the std fields for asana (assignee and due_on as the ones i’ve found so far looking at ‘events’ and then you can set a hook on ‘custom_fields’ which handles ALL fields you add.

and in every case, they tell you the gid of what changed, then you have to read it and figure out what the value is (another enhancement suggestion, send the new value and the label for the field, not just the gid).

THIS SHOULD BE IN THE DOC, it shouldn’t be up to the developer to figure this out (off soapbox)… thank goodness for this forum and Phil_Seeman Forum Champion

1 Like

I don’t pretend I understand the full reasoning (nor do I know the details of the decision), but apparently they’ve chosen not the send the actual value for security reasons:

It looks like the reasoning for not exposing primitive fields was security related.

I agree that our docs are unclear here. :frowning: Let me know if you have a suggestion on how we can improve, otherwise I’ll try and come up with something.

Our docs have a schema section which shows fields on the task object Tasks. The idea is suppose to be that all of those fields are valid fields to pass (which is why we don’t explicitly list out the options elsewhere), but it’s pretty unclear how custom_fields fit into that.