User Updated Webhook fires on user registrated

Hey @vargaszabolcs – thank you very much for reaching out!
Indeed it is possible that the update trigger first. The cause for that is most likely a third-party plugin that re-saves the user once it was created, causing the update hook to fire as well.
The way you can prevent this, depends on the plugin that is causing the trigger to fire.
To figure that out, I suggest deactivating the other plugins and trying it until you see the update webhook was triggered as well.
I hope this helps you so far. Do let me know in case you have any further questions in the meantime. ??

Hi @ironikus ! Thanks for the answer, now I know that it’s not default behaviour with this hook.

Hey @vargaszabolcs – Thank you for coming back to us. Is there any further question I can help you with?

In case that’s for the relevance of you, there is a way of how you can filter requests and catch them before they are executed. (Be aware that the next details require some technical understanding to make it work).

We have a WordPress filter available that allows you to manipulate the triggers that are collected within the post-delay feature of the current instance: https://ironikus.com/docs/knowledge-base/filter-delayed-triggers/

This trigger collects all webhook triggers that will be fired and using the hook above, you can also deregister them if necessary.
This way, you could remove specific calls that you do not want to fire within the same instance of WordPress.