Webhooks: differentiate a human vs an API call update trigger

Hi there!

Is there a way to be able to differentiate a webhook trigger from a manual human update on a board vs an API call update?
Or is there any way to prevent a webhook trigger when doing an API request update on a board with an active webhook (Column value change), so I just get a webhook posted when the board is manually updated?

Thanks for the help!


Hello there @CristianVB!

I can think of a workaround. If you are using a specific “dummy” user’s API key to make the HTTP requests, then you can check the userId of the user who updated the board and if the userId is from the “dummy” user, then you know it came from the API call.

What do you think?

Hey Matias!
Thanks for the reply. Sounds like it could work. Only downside that I see, is that the update wont reflect the real user that made the change, but I think we can live with that for now :smiley:
Thanks for the help!

@Matias.Monday We have the same problem with General Caster app.

If the GC integration uses the “When any column changes” trigger and we change a column thru API, the trigger is fired again in a loop.
The current workaround is to check if the trigger has been generated by the column we have just updated. In this case we stop the execution.
This is not an optimal solution because this means that the trigger is actually “When any column (except the one that will be updated by General Caster) changes”.
In addition to all data you send to a webhook when an event is fired, it would be really useful to have a couple of new fields:

triggerEventSourceType = ["user", "monday", "api"]
triggerEventSourceId   = userId, appId, ...

cc @dipro

Hello @rob!

Thank you for the feedback!

I’ve shared it with the team :slightly_smiling_face:

+1 to Rob’s suggestion.
Would be really nice if it would be possible to pass some optional context attributes to the API, that would be added to the webhook body.


Hi @Matias.Monday
I’m upping this request.
Knowing who fires an event it really important:

  • to prevent loops when the change in a column calls an action that changes the same column;
  • to prevent problems when multiple changes made thru API are performed to the same column;
  • to perform an operation only when an event is actually triggered by a user.

Hello @rob!

I have shared this request with the team. Your vote was added to it :slightly_smiling_face: