Any chance the user_badge webhooks could include username along with user_id? Currently the payload for a user_badge event looks like this: { "user_badge": { "id": 123456, "granted_at": "2026-09-25T14:54:42.073Z", "created_at": "2026-09-26T05:34:12.965Z", "post_id": 234567, "p…

FWIW, my workaround for non-standard webhooks or when I need additional data is to do it via Workflows and then send that to n8n.

[이미지] burke: I’m creating an external service that I was hoping to trigger when specific badge(s) are granted; however, it needs the username and badge webhooks only returns user IDs. Fwiw, fetching username from user id is just one API call away, unless you’re manually granting thousands of …

[이미지] putty: FWIW, my workaround for non-standard webhooks or when I need additional data is to do it via Workflows and then send that to n8n. Thanks! I’ll look into Workflows.

[이미지] itsbhanusharma: Fwiw, fetching username from user id is just one API call away, unless you’re manually granting thousands of badges in an instant, you should be fine with the default API limits. That’s great to hear! Could you please provide details about that one API call that isn’t /a…

What’s the issue with an admin API key? This is supposed to be a background job ig?

[이미지] itsbhanusharma: What’s the issue with an admin API key? This is supposed to be a background job ig? Principal of Least Privilege. This external service will be running on another server and only needs read access to Discourse to do it’s job. The fewer master keys floating around across …

This brings up the interesting point of why isn’t there a public-facing endpoint to get a user by id that shows only public fields, if login_required is not selected. It would be useful, no? I wonder why it was not made. Or maybe only logged in users could get such a privilege, but either way, there…

This is because for all matters and purposes user IDs are essentially an internal convention in discourse and we are expected to rely on usernames that are much more prominent across the board.

Which brings us back to the original request. The webhook should adhere to that concept and send the username, not the user ID.

[이미지] RGJ: Which brings us back to the original request. The webhook should adhere to that concept and send the username, not the user ID. Agreed! This seems like the best solution. Adding username and granted_by_username and deprecating user_id and granted_by_id could allow for a non-breakin…

user_badge 웹훅 페이로드에 사용자 이름을 포함할 수 있을까요?

제품 지원

RGJ (Richard - Communiteq) 9월 30, 2026, 7:13오전 10

이로써 원래의 요청으로 돌아가게 됩니다. 웹훅은 해당 개념을 따르도록 사용자 ID가 아니라 사용자 이름을 전송해야 합니다.

글		댓글	조회수
Webhooks feedback Development	33	11400	3월 21, 2017
Grant a custom badge through the API Integrations rest-api , how-to	9	8064	11월 18, 2023
Improved badge granting workflow Feature badges , completed	29	5254	1월 23, 2018
Wishlist: visual cue for "user got a badge for this post" Feature badges	36	2200	12월 5, 2024
Bulk Award a badge to a set of users Announcements badges , new-feature	28	6534	3월 31, 2025

user_badge 웹훅 페이로드에 사용자 이름을 포함할 수 있을까요?

Related topics