Os nomes de usuário poderiam ser incluídos no payload do webhook user_badge?

Suporte
,
1

Existe alguma possibilidade de os webhooks de user_badge incluírem o username junto com o user_id? Atualmente, o payload de um evento de user_badge parece com o seguinte:

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

Obter o username para um user_id (e para o granted_by_id, caso não seja -1) requer uma chamada adicional para /admin/users/{user_id}.json, o que não apenas exige requisições extras, mas também requer privilégios de administrador, pelo menos até onde eu pude verificar.

Existe uma maneira de obter o username para um user_id específico usando uma chave de API sem precisar de privilégios de administrador?

Estou criando um serviço externo que eu esperava disparar quando badges específicos fossem concedidos; no entanto, ele precisa do username e os webhooks de badges retornam apenas IDs de usuário. :confused:

2

A título de informação, minha solução alternativa para webhooks não padrão ou quando preciso de dados adicionais é fazer isso por meio de Workflows e, em seguida, enviar isso para o n8n.

3

Só para dizer, obter o nome de usuário a partir do ID do usuário é apenas uma chamada de API. A menos que você esteja concedendo manualmente milhares de distintivos instantaneamente, você deve estar bem dentro dos limites padrão da API.

4

Obrigado! Vou dar uma olhada nos Workflows.

5

Que bom saber! Você poderia fornecer detalhes sobre essa chamada de API que não é /admin/users/{user_id}.json (que requer privilégios de administrador)? Não consegui encontrar um endpoint para fazer isso com uma chave de API que não exigisse privilégios de administrador.

6

Qual é o problema com uma chave de API de administrador? Isso deveria ser um job em background, né?

7

Princípio do Menor Privilegio. Este serviço externo será executado em outro servidor e só precisa de acesso de leitura ao Discourse para realizar sua função. Quanto menos chaves mestras circulando pela infraestrutura, melhor.

8

Isso levanta o ponto interessante de por que não existe um endpoint público para buscar um usuário por ID que mostre apenas os campos públicos, caso login_required não esteja selecionado. Seria útil, não? Me pergunto por que isso não foi feito. Ou talvez apenas usuários conectados pudessem ter esse privilégio, mas, de qualquer forma, deveria haver alguma maneira de acessá-lo sem usar o endpoint de administrador…

@burke Uma solução alternativa mais trabalhosa seria olhar para /groups/trust_level_0/members.json (ou qualquer grupo mais específico) e encontrar o usuário pelo ID, já que essa rota também contém o nome de usuário.

9

Isso ocorre porque, em todos os aspectos e propósitos, os IDs de usuário são essencialmente uma convenção interna no discourse, e espera-se que confiemos nos nomes de usuário, que são muito mais proeminentes em geral.