# Missing webhook user events - by design or oversight?

**URL:** https://meta.discourse.org/t/missing-webhook-user-events-by-design-or-oversight/273579
**Category:** Feature
**Tags:** webhooks
**Created:** [August 2, 2023, 12:58am UTC](https://meta.discourse.org/t/missing-webhook-user-events-by-design-or-oversight/273579 "2023-08-02T00:58:25Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![mdoggydog](https://avatars.discourse-cdn.com/v4/letter/m/82dd89/32.png) [@mdoggydog](https://meta.discourse.org/u/mdoggydog)
#### Post date: [August 2, 2023, 12:58am UTC](https://meta.discourse.org/t/missing-webhook-user-events-by-design-or-oversight/273579/1 "2023-08-02T00:58:25Z")

</div>

There are a bunch of actions that I would expect (and would like) to generate webhook _user_ events, but they don’t. Before I go filing bug reports (or submitting PR’s), I’d like to get a better idea of why that is.

| action | expected _user_ event |
| --- | --- |
| account deactivated by admin | user\_logged\_out |
| account anonymized by admin | user\_logged\_out |
| user logs out self via “Log out all” button | user\_logged\_out |
| — | — |
| added to a group | user\_updated |
| removed from a group | user\_updated |
| trust level increased/decreased | user\_updated |
| moderator status granted/revoked | user\_updated |
| admin status granted/revoked | user\_updated |
| unsuspended | user\_updated |
| silenced/unsilenced | user\_updated |

- The first group of three are all actions that result in a global, all-sessions-invalidated logout of the user — but unlike other similar actions (e.g., user logged out by admin), these three don’t generate a _user/user\_logged\_out_ event (or any other event).
- Being added/removed from a group generates a _group\_user_ event, but not a _user_ event. The _group\_user_ events aren’t very useful by themselves, since they only contain the internal numeric id’s of groups and users. On the other hand, the `"user"` record sent upon a _user_ event contains really useful information for all the groups to which a user belongs, including the names of the groups and details about the user’s relationships with the groups.
- When a user’s trust level is increased, a _user\_promoted_ event is emitted, which contains data which is very similar to, but not quite the same, as a _user_ event. When a user’s trust level is decreased, no similar event is emitted at all.
- No _user_ events are emitted when moderator or admin status changes. (There is indirect user-specific evidence of grant actions via _group\_user_ events; there is no user-specific evidence of revoke actions.)
- Suspending a user does emit a _user/user\_logged\_out_ event (with `"suspended_reason"` and `"suspended_till"` fields indicating the suspension)… but there is no event when a user is unsuspended. No events whatsoever are emitted when a user is silenced or unsilenced.

Are any of these omissions on purpose?

My general thinking is “If the data in a _user_ event `"user"` record would have changed, then a _user_ event should be emitted.” That probably encompasses more situations that do not currently evoke events. However, the few I itemized in the table above are the ones I care about the most at the moment because they all involve changes to a user’s authorization status.