Webhook Creation Failure

English Forum Developers & API
, ,
14

Hi @anon2981095,

Our webhooks can be tricky to work with. My recommendation on learning how to establish the right webhook with filters that you want is to first establish a webhook with no filters at all then perform an action on a resource and observe what events you get. Then use this information from the events to create your filter(s).

Let’s take your ask for example: “when i update the status of task in that project, i don’t see any event getting triggered and calling my target URL”

Step 1: Establish a webhook with no filters and observe the events
EX: Webhook Request Body → this is basically saying give me all events that happen within a project (since tasks are a part of a project you will get events about tasks, the project itself, etc…)

{
  "data": {
    "resource": "<YOUR_PROJECT_GID>",
    "target": "<YOUR_TARGET_URL>"
  }
}

Step 2: Trigger something in that resource. Since we established a webhook to watch events that happen in a project resource we can try to mark a task as complete and seeing what events are being sent to your webhook server.
EX: Result

[
  {
    user: { gid: '<USER_GID>', resource_type: 'user' },
    created_at: '2023-09-06T17:07:12.000Z',
    action: 'changed',
    parent: null,
    change: { field: 'modified_at', action: 'changed' },
    resource: { gid: '<PROJECT_GID>', resource_type: 'project' }
  },
  {
    user: { gid: '<USER_GID>', resource_type: 'user' },
    created_at: '2023-09-06T17:07:11.913Z',
    action: 'changed',
    resource: {
      gid: '<TASK_GID>',
      resource_type: 'task',
      resource_subtype: 'default_task'
    },
    parent: null,
    change: { field: 'completed', action: 'changed' }
  },
  {
    user: { gid: '<USER_GID>', resource_type: 'user' },
    created_at: '2023-09-06T17:07:11.913Z',
    action: 'changed',
    resource: {
      gid: '<TASK_GID>',
      resource_type: 'task',
      resource_subtype: 'default_task'
    },
    parent: null,
    change: { field: 'completed_at', action: 'changed' }
  },
  {
    user: { gid: '<USER_GID>', resource_type: 'user' },
    created_at: '2023-09-06T17:07:12.003Z',
    action: 'added',
    resource: {
      gid: '<STORY_GID>',
      resource_type: 'story',
      resource_subtype: 'marked_complete'
    },
    parent: {
      gid: '<TASK_GID>',
      resource_type: 'task',
      resource_subtype: 'default_task'
    }
  }
]

Step 3: Pick out the event that you are interested in. In this case since we want to receive events about task being marked complete we probably want to look at:

  {
    user: { gid: '<USER_GID>', resource_type: 'user' },
    created_at: '2023-09-06T17:07:11.913Z',
    action: 'changed',
    resource: {
      gid: '<TASK_GID>',
      resource_type: 'task',
      resource_subtype: 'default_task'
    },
    parent: null,
    change: { field: 'completed', action: 'changed' }
  }

Step 4: Take this information and establish a new webhook just to filter for the event that you are interested in
EX: New webhook request body

{
  "data": {
    "resource": "<YOUR_PROJECT_GID>",
    "target": "<YOUR_WEBHOOK_URL>",
    "filters": [
      {
        "resource_type": "task",
        "action": "changed",
        "fields": [
            "completed"
        ]
      }
    ]
  }
}

Step 5: Test out the new webhook to see if the filter works → Mark another task as complete and see what event you get
EX: Response

[
  {
    user: { gid: '<USER_GID>', resource_type: 'user' },
    created_at: '2023-09-06T17:22:50.727Z',
    action: 'changed',
    resource: {
      gid: '<TASK_GID>',
      resource_type: 'task',
      resource_subtype: 'default_task'
    },
    parent: null,
    change: { field: 'completed', action: 'changed' }
  }
]

NOTE: this TIP doesn’t really work for higher level webhooks since we will force you to provide a filter when you try to establish a webhook at a higher level EX: → if you provide a WORKSPACE_GID as a value for resource when establishing a webhook we will ask that you provide a filter → in this case you might want to use this trick at a lower level to observe changes to a lower level resource than apply it to the workspace resource.

  • EX: If I want to get events about project name changes in a portfolio (we consider portfolios higher level webhook) I can do step 1 but for resource provide a PROJECT_GID → change name of project → look at event → go back and establish webhook with resource value as PORTFOLIO_GID → add filters about project name changes that I saw in the previous step.
2 Likes