O que um App nunca alcança

As três camadas: DM, presença, moderação

• Conversa privada. Não é configuração: nenhuma moldura de /api/me/* aceita credencial de App, o Gateway roteia eventos de DM por id de conta (que App não tem), e a DM é cifrada ponta a ponta. Três camadas independentes, e o metadado de quem fala com quem é justamente o que o funil protege.
• Presença de gente. Quem está online e quem está em qual sala de voz não atravessa o funil do App. Não existe família de intent para isso, e anunciar uma que nada entrega seria promessa que o Gateway não cumpre.
• Moderação sobre pessoas. Expulsar, banir, tirar da chamada e silenciar ficam fora do conjunto de permissões instaláveis — a seção abaixo diz por quê.

O catálogo de eventos marca cada um desses cortes linha a linha, em Eventos.

Por que a moderação não é instalável

As 5 permissões de agir sobre pessoas — expulsar_membros, banir_membros, desconectar_de_chamada, mutar_microfone, mutar_audio — ficam fora do conjunto instalável: elas não são escopo que uma instalação possa autorizar.

Um cargo ainda pode carregá-las, e a interseção as zera. Este é o ponto, e ele mudou de motivo em 30/08/2026: não é a posição que impede a escalada, é o teto. O posto de um App é o do cargo mais alto que ele tiver, como o de qualquer membro — mas sem o escopo autorizado, cargo nenhum produz capacidade. Conceder o que não produz nada é armadilha; deixar de fora é honesto.

As rotas que recusam Bearer

As rotas abaixo existem, e recusam a credencial de App com 401. Não é esquecimento em todos os casos, mas em alguns é falta de rota — a lista está aqui para você não gastar uma tarde descobrindo sozinho.

• Criar e excluir servidor; ícone, banner e configurações; convites; descoberta; registro de auditoria.
• Categorias (criar, editar, apagar) e as três rotas de ordem (canais, cargos, categorias).
• Subir anexo e avisar que está digitando. É por isso que attachments, no envio de mensagem, só reaproveita a chave de um anexo que já existe.
• Expulsar, banir, tirar da chamada e silenciar — coerente com o conjunto de escopos instaláveis, que não os contém.
• Tudo em /api/me/*, incluindo conversas privadas — e também a configuração do App (endereço do endpoint, escopos declarados, credenciais). Isso é de propósito: um App que trocasse o próprio endpoint com o Bearer transformaria um token vazado em redirecionamento permanente das interações. Quem configura é você, no portal.

E não existe rota para o App listar onde ele está instalado, nem rota de perfil público de App. Hoje o App descobre os servidores pelos eventos que recebe.

Os códigos que essa fronteira produz

Sete códigos de erro do catálogo nunca chegam a um App, porque saem justamente dessas molduras — ORIGIN_REJECTED, NOT_FOUND, PLATFORM_OWNER_ONLY, ACCOUNT_RESTRICTED, ACCOUNT_SUSPENDED, ACCOUNT_BANNED e DM_NOT_FOUND. Eles têm tabela própria em Erros.

O que não existe, e por quê

• Escopo OAuth de usuário. Não há consentimento individual nem redirect URI, e não há troca de código por token: o App age sempre como ele mesmo. Quem autoriza é quem administra o servidor, na tela de instalação.
• Escopo por canal. O teto da instalação é do servidor inteiro. O que existe por canal é o eixo de visibilidade e capacidade, e ele só TIRA — nenhum override amplia um App além dos escopos autorizados.
• Webhook de entrada. Não existe endereço que aceite um POST seu e vire mensagem: quem escreve é o app.rest, com a credencial.
• Monetização, diretório de Apps, Apps instaláveis por usuário, atividades embutidas e verificação de App. Estão registrados como decisão, e não como esquecimento — e não há data prometida para nenhum deles.

O que existe e quase ninguém espera: a moderação da plataforma pode suspender, restringir ou banir um App, e pode revogar a credencial dele sem excluí-lo. Criar e gerenciar um App diz o que cada uma fecha.