¿Se podrían incluir los nombres de usuario en el payload del webhook user_badge?

Soporte
,
1

¿Hay alguna posibilidad de que los webhooks de user_badge incluyan username junto con user_id? Actualmente, el payload para un evento de user_badge se ve así:

{
  "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
  }
}

Obtener el username para un user_id (y para granted_by_id si no es -1) requiere una llamada adicional a /admin/users/{user_id}.json, lo cual no solo implica solicitudes adicionales, sino que, según entiendo, también requiere privilegios de administrador.

¿Existe alguna forma de obtener el username para un user_id dado usando una clave de API sin necesidad de privilegios de administrador?

Estoy creando un servicio externo que esperaba poder activar cuando se otorguen insignias específicas; sin embargo, necesito el nombre de usuario y los webhooks de insignias solo devuelven identificadores de usuario. :confused:

2

Por cierto, mi solución alternativa para webhooks no estándar o cuando necesito datos adicionales es hacerlo a través de Workflows y luego enviar eso a n8n.

3

Por cierto, obtener el nombre de usuario a partir del ID de usuario está a solo una llamada a la API de distancia; a menos que estés otorgando manualmente miles de insignias al instante, deberías estar bien con los límites de la API por defecto.

4

¡Gracias! Voy a investigar Workflows.

5

¡Me alegra saberlo! ¿Podrías proporcionar detalles sobre esa llamada a la API que no es /admin/users/{user_id}.json (que requiere privilegios de administrador)? No pude encontrar un punto de acceso para hacer esto con una clave de API que no requiriera privilegios de administrador.

6

¿Cuál es el problema con una clave de administrador? Esto debería ser un trabajo en segundo plano, ¿no?

7

Principio de privilegio mínimo. Este servicio externo se ejecutará en otro servidor y solo necesita acceso de lectura a Discourse para realizar su función. Cuantas menos claves maestras circulen por la infraestructura, mejor.

8

Esto plantea el interesante punto de por qué no existe un punto de acceso público para obtener un usuario por su ID que muestre únicamente los campos públicos, si no se ha seleccionado login_required. ¿No sería útil? Me pregunto por qué no se implementó. O tal vez solo los usuarios iniciados en sesión pudieran acceder a ese privilegio, pero de todas formas, debería haber alguna manera de acceder a él sin recurrir al punto de acceso de administración…

@burke Una solución alternativa más engorrosa sería consultar /groups/trust_level_0/members.json (o cualquier grupo más específico) y buscar al usuario por su ID, ya que esa ruta también contiene el nombre de usuario.