Does the Event API give me details of the event, or just a notification that an event happened?

Asana newbie here so forgive a potentially silly question…

I’ve been playing with the Asana API to create webhooks to receive notifications about changes to tasks. This all works fine, and I do receive events as they happen, so no issues getting set up.

My question is about the payload of the POST from Asana to my endpoint that receives events. The POST I get only tells me that something changed - not what changed. This isn’t particularly useful to me as I need to know what actually changed.

Am I missing something here, or is the Asana Event API purposely designed this way?

I am trying to avoid having to capture task fields and store them myself elsewhere so that I have a point of comparaison when I receive a “changed” event. Has anyone else had to do this and maybe has some tips to share?

1 Like

Hi @Jason_Dark,

Your assessment is exactly correct: the Events API does not tell you what fields within an object changed, only that something changed on that object. The only way to know exactly what changed is, as you say, to store data yourself and compare.

Thanks @Phil_Seeman, makes sense now. Will have to hold a record of task fields then!

Yeah, I’m afraid so! (That’s what I do in Flowsana.)

We have an enhancement coming soon that could help with this!

While we always want to be clear that using stories for task changes is problematic (stories are designed for human consumption, and making multiple changes of the same kind at once can “collapse” them to reduce noise for human users of Asana) they will contain some of this information now (if you ask for it with opt_fields) and we’ll document it soon!

Here is the default payload returned from a story where I changed the description (the field on a task called “notes” in our API):

{
  "user": {a user object and its fields}
  "created_at": "2019-01-30T19:41:28.755Z",
  "type": "story",
  "action": "added",
  "resource": {
    "gid": "1107407559918819",
    "id": 1107407559918819,
    "resource_type": "story",
    "created_at": "2019-01-30T19:41:28.592Z",
    "created_by": {
      "gid": "153678405088703",
      "id": 153678405088703,
      "resource_type": "user",
      "name": "Matt Bramlage"
    },
    "type": "system",
    "text": "added the description"
  },
  "parent": {a task object and its fields}
}

As you notice, you can’t tell what changed. However, you can ask for resource_subtype with opt_fields now - it will filter down to only the fields you request (as in all requests with opt_fields), but check out what this event looks like when I request resource_type and resource_subtype:

curl -v --request GET --header "Authorization: Bearer $ASANA_PERSONAL_ACCESS_TOKEN" "https://app.asana.com/api/1.0/projects/157953484489631/events?sync={a sync token}&opt_fields=resource.(resource_type|resource_subtype)"

{
  "resource": {
    "gid": "1107407559918819",
    "id": 1107407559918819,
    "resource_type": "story",
    "resource_subtype": "notes_changed"
  }
}

:tada:

If you need to get the content of the notes afterwards, you still need to fetch the field; and if you need to know what they were before you still have to diff them against your own stored copy of what there was before, but at least you can see what I did to create the story now.

@Joe_Trollo is investigating ways we can bring this behavior to webhooks as well to enable something similar when we send out webhook events!

1 Like

Hey @Matt_Bramlage,

As @Jeff_Schneider and I have discussed :slight_smile: this would be awesome IF the time interval for filtering out changes could be reduced dramatically. I know that’s driven by the UI design goal of not cluttering up the activities list in a task detail pane, but if Jeff didn’t note it previously, please consider this a formal request for reducing the 24 hours to maybe 30-60 seconds or so. Thanks!

Thanks @Matt_Bramlage, I had played with the Story API to get more detail on changes and it’s good to know that I can query this with specific fields. Looking forward to watching the Asana APIs grow and evolve!

@Jason_Dark and @Phil_Seeman, I don’t understand what’s the purpose of tracking exactly what was the change, since you still need to fetch the full resource why not just update your app seamlessly to match all fetched fields from asana.

So @Phil_Seeman why did you suggest to do a comparison? what do I gain by knowing what was changed, why not just override the whole targeted resource.

I am digging in these details since I am currently in the process of implementing a Integration with asana, your knowledge maybe helpful.

Because Jason’s requirement was specifically how to know what changed.

Hey, i found this thread when looking for a issue i experienced. I have been using webhooks for some time and i created a new user in a new workspace and i noticed that the payload objects looks different on that user than on the old users i have. And this object that you have pasted here is what i see on the new user. Is there anywhere i can read about that change? Im guessing that it will be updated on the old users at some point as well? =)

Thanks!

Because in my case I needed to know what exactly had changed in the resource.