Stop making webhook calls with users that don't exist

Developer Forum
1

From time to we get spammed with hook calls from a user with an ID/GUID of 01010001-0000-0000-0000-111111111111 - obviously an internal user that does not really exist. I have no idea what you are doing, because yesterday this happened more than 800 times. I have also seen this happening before. This causes a lot of issues and especially unneeded API calls. Please fix this.

image
image2174×1194 201 KB

2

@thomas.poechtrager can you provide us with an id of the entity you see this issue? The id of the user is the user we use for internal automations (like the automations you can configure) so they are expected in a lot of situations.

But we can check the details of the case and let you know why the webhook was executed in this case.

3

Hi @thomas.poechtrager, thanks for reporting this. This is an internal id as you correctly pointed out, which is used for any kind of change on an entity triggered from within awork, such as any user-defined automation, data consistency automation, etc.

Do you have a trace-id from any of those webhook requests so I can identify what caused this massive batch of events?

I will take this back to the team to discuss. My first impression is that skipping these events in the webhooks would lead to external data not being consistent as webhook receivers would have no way to receive these changes otherwise.

What I could imagine as an alternative is to return some basic user information if this id is passed to a user endpoint.

Again, will take this to the team to discuss the best way forward here.

4

Thank you guys for the quick reply.

The webhook is triggered by the ‚project task deleted‘ event.

Sadly, I don’t have a trace id. We don’t save them.

I can only provide you the exact timestamps when it happened. For example [2025-06-04 12:40:12] (UTC+1) for our workspace ‚https://plum-mindblowing-icons.awork.com/‘.

What I could imagine as an alternative is to return some basic user information if this id is passed to a user endpoint.

That would be great, so we understand what’s going on and know it’s caused by internal automation.

5

Thanks for the details, we’ll take a look.

I just checked and we actually return the user when requested by id:

curl --request GET \
  --url https://api.cwork.io/api/v1/users/01010001-0000-0000-0000-111111111111 \
  --header 'accept: application/json'

returns

{
	"id": "01010001-0000-0000-0000-111111111111",
	"firstName": "awork",
	"hasImage": true,
	"isDeactivated": false
}

How are you checking for the users?

6

I am currently downloading the workspace’s user table and look up the user from there - not ideal. I need to fix that. Ideally, I’d prefer not to retrieve internal webhooks, as they’re not relevant to the end-user. I mean, it’s not a hook triggered by one of our users. :thinking:

7

Like we mentioned before, those could be changes made by automations created by actual users, so we will need to send those webhook events.

One thing you can try is to enable the first-level properties only toggle. This reduces the events to first-level properties of tasks or whichever entity you’re subscribing to instead of also the nested properties if you are not interested in those changes. This can significantly reduce the number of events you receive and may have skipped them entirely in this case.