Können Benutzernamen im Webhook-Payload von user_badge enthalten werden?

Unterstützung
,
1

Gibt es eine Möglichkeit, dass die user_badge-Webhooks neben der user_id auch den username enthalten? Derzeit sieht die Nutzlast für ein user_badge-Event wie folgt aus:

{
  "user_badge": {
    "id": 123456,
    "granted_at": "2026-09-25T14:54:42.073Z",
    "created_at": "2026-09-26T05:34:12.965Z",
    "post_id": 234567,
    "post_number": 1,
    "badge_id": 123,
    "user_id": 456,
    "granted_by_id": -1,
    "topic_id": 56789
  }
}

Um den Benutzernamen für die user_id (und granted_by_id, falls dieser nicht -1 ist) zu erhalten, ist ein zusätzlicher Aufruf an /admin/users/{user_id}.json erforderlich. Das erfordert nicht nur zusätzliche Anfragen, sondern benötigt nach meinem Verständnis auch Administratorrechte.

Gibt es eine Möglichkeit, den username für eine gegebene user_id mit einem API-Schlüssel abzurufen, ohne Administratorrechte zu benötigen?

Ich erstelle einen externen Dienst, den ich hoffentlich auslösen kann, wenn bestimmte Abzeichen vergeben werden. Dafür benötige ich jedoch den Benutzernamen, während die Abzeichen-Webhooks nur Benutzer-IDs zurückgeben. :confused:

2

Nur am Rande: Mein Workaround für nicht standardmäßige Webhooks oder wenn ich zusätzliche Daten benötige, ist, dies über Workflows zu erledigen und das dann an n8n zu senden.

3

Nur als Hinweis: Den Benutzernamen aus der Benutzer-ID abzurufen, ist nur ein API-Call entfernt. Es sei denn, du vergibst manuell Tausende von Abzeichen in einem einzigen Moment, dann solltest du mit den Standard-API-Limits gut zurechtkommen.

4

Danke! Ich werde mir Workflows genauer ansehen.

5

Das ist gut zu hören! Könntest du bitte Details zu diesem einen API-Aufruf liefern, der nicht /admin/users/{user_id}.json ist (was Administratorrechte erfordert)? Ich konnte keinen Endpunkt finden, mit dem man dies über einen API-Schlüssel tun kann, der keine Administratorrechte benötigt.

6

Was ist das Problem mit einem Admin-API-Schlüssel? Das soll doch eigentlich ein Hintergrundjob sein, oder?

7

Das Prinzip der geringsten Berechtigung. Dieser externe Dienst läuft auf einem anderen Server und benötigt nur Lesezugriff auf Discourse, um seine Aufgabe zu erfüllen. Je weniger Master-Keys in der Infrastruktur umherwandern, desto besser.

8

Das wirft die interessante Frage auf, warum es keinen öffentlichen Endpoint gibt, mit dem man einen Benutzer anhand seiner ID abrufen kann und dabei nur öffentliche Felder angezeigt werden, sofern login_required nicht ausgewählt ist. Wäre das nicht nützlich? Ich frage mich, warum das nicht so gemacht wurde. Vielleicht können nur angemeldete Benutzer auf eine solche Berechtigung zugreifen, aber auf jeden Fall sollte es eine Möglichkeit geben, darauf zuzugreifen, ohne den Admin-Endpoint zu nutzen…

@burke Ein aufwendigerer Workaround wäre, in /groups/trust_level_0/members.json (oder einer noch spezifischeren Gruppe) nach dem Benutzer anhand seiner ID zu suchen, da dort auch der Benutzername enthalten ist.