Treze artigos saíram deste blog entre 19 de agosto e 1º de setembro de 2026, os quatro últimos com intervalo de praticamente 24 horas entre um e outro. Dentro do WordPress, cada um deles foi um evento só: um post que mudou de estado. O trabalho aparece depois, quando esse evento único precisa virar mensagem em canais que não combinaram nada entre si: o Discord aceita quase o texto cru, o Telegram cobra atenção na pontuação e o Teams desligou em maio a porta que todo mundo usava, derrubando quem não tinha migrado.
Acompanhamos o mesmo aviso saindo pelos três, com a documentação oficial de cada plataforma aberta hoje e os dados deste blog na mão. Quem nunca configurou um desses gatilhos encontra a explicação de base em o que é um webhook.
Seis dos treze posts foram editados depois de já estarem no ar
Dá para conferir isso em qualquer blog sem abrir o painel: a API REST do WordPress devolve date_gmt, a hora da publicação, e modified_gmt, a da última alteração. Neste blog, seis dos treze artigos têm o segundo campo maior que o primeiro. Em três deles a diferença passa de 37 horas: o texto ficou no ar quase dois dias antes de alguém voltar e corrigir alguma coisa.
Prender o disparo ao salvamento do post significa mandar seis mensagens repetidas em treze publicações, sem contar autosave e revisão, que passam pelo mesmo caminho. O que interessa é a transição de estado: o post saiu de rascunho, agendado ou pendente e chegou em publicado. O WordPress entrega essa transição com o estado anterior e o novo lado a lado, e a comparação entre os dois é a trava inteira. Se o estado anterior já era publicado, não é publicação nova, é edição, e ninguém precisa ser avisado de novo.
O caso agendado é o que mais quebra implementação caseira. Um post que vai ao ar às sete da manhã de domingo muda de estado dentro do cron do WordPress, sem navegador aberto, sem requisição de ninguém. Se o disparo depende de algo que só existe durante a edição no painel, o artigo publica e o aviso não sai. Teste exatamente esse cenário antes de confiar na esteira: agende um post para daqui a dois minutos, feche o navegador e volte depois para ver se a mensagem chegou.
O Discord aceita quase o texto cru
Dos três canais, o Discord é o de menor cerimônia. A documentação da plataforma é explícita quanto a isso: os webhooks não exigem um usuário bot nem autenticação para funcionar. O envio é um POST para /webhooks/{webhook.id}/{webhook.token}, e o segredo é a própria URL. Quem tem a URL manda mensagem no canal, o que também define o tamanho do estrago se ela vazar em um repositório público.
O corpo precisa trazer pelo menos um entre content, embeds, components, file e poll. Para um aviso de artigo novo, os dois primeiros bastam. O campo content aceita até 2.000 caracteres, e cada mensagem comporta até 10 embeds, aquele bloco com barra colorida na lateral onde cabem título, descrição, imagem e link.
Em caso de sucesso, o Discord devolve 204 No Content, sem corpo nenhum: a mensagem entrou e você não recebe o identificador dela. Se o seu código precisa guardar esse id para editar ou apagar o aviso depois, o envio tem que ir com wait=true na query, e aí a resposta vira 200 com o objeto da mensagem. Trocar um pelo outro no meio do caminho é o tipo de mudança que quebra um integrador silenciosamente, porque o envio continua funcionando e só o pós-processamento para.
Quando o limite aparece, vem um 429 com um corpo JSON que traz retry_after, o número de segundos a esperar antes de tentar de novo. Junto vêm os cabeçalhos X-RateLimit-Remaining e X-RateLimit-Reset-After, que dizem quanto sobrou e quando a janela reabre. O teto global documentado é de 50 requisições por segundo, folgadíssimo para quem publica um artigo por dia. O risco real é outro: requisições inválidas repetidas contam em um balde separado, e chegar a 10.000 delas em 10 minutos rende restrição temporária de IP. Um laço que insiste em uma URL de webhook apagada chega lá sozinho. O significado de cada código de resposta está destrinchado em erro de webhook no WordPress.
O Telegram troca o segredo de lugar e cobra pela pontuação
No Telegram o desenho muda. O segredo não está em uma URL sorteada por canal, está no caminho da chamada: https://api.telegram.org/bot<token>/sendMessage. O mesmo token serve para qualquer conversa em que o bot esteja, o que significa que ele vale mais do que uma URL de webhook do Discord e precisa de tratamento de senha. Os dois parâmetros obrigatórios são chat_id e text, e a documentação limita o texto a 4.096 caracteres depois do processamento das entidades. O passo a passo de criar o bot e descobrir o identificador do grupo está em bot do Telegram no WordPress.
A resposta também segue outra lógica. O envelope sempre traz o campo booleano ok. Deu certo, o conteúdo vem em result. Deu errado, ok vem falso, acompanhado de error_code e de uma description em texto legível que costuma dizer exatamente o que está errado. Ler apenas o status HTTP e ignorar o corpo é o erro mais comum de quem integra o Telegram pela primeira vez, porque a descrição é a parte útil.
A armadilha que aparece na terceira semana é a formatação. Com parse_mode em MarkdownV2, a documentação exige escapar qualquer caractere entre os códigos 1 e 126 que faça parte da marcação, incluindo _, *, [, ], (, ), ~, ` e >. Títulos de artigo estão cheios disso. Um parêntese, um sublinhado no slug, um sinal de maior em uma citação e a mensagem inteira volta como erro de parse, não como texto sem negrito. O modo HTML é bem menos exigente e resolve a maioria dos avisos de publicação com <b> e <a>, desde que &, < e > sejam escapados no texto.
De volume o Telegram não reclama: a documentação fala em até 30 mensagens por segundo no envio a usuários. Quando o controle de fluxo entra, a resposta traz retry_after com o tempo de espera, como no Discord, só que dentro dos parâmetros do erro e não em um cabeçalho.
O Teams mudou de porta em maio e não avisou o seu servidor
Este é o canal que quebrou de verdade em 2026. A Microsoft aposentou os conectores do Office 365 dentro do Teams, e depois de vários adiamentos o desligamento aconteceu entre 18 e 22 de maio de 2026. A frase no anúncio oficial não deixa margem: depois dessas datas, os conectores do Office 365 não funcionam mais. Quem tinha um incoming webhook antigo colado em um plugin, em um script de deploy ou em um monitor de uptime viu a integração parar sem nenhuma mudança do seu lado.
Dá para ver o estrago em projeto aberto. No repositório do Home Assistant, uma issue de 3 de junho de 2026 registra que a notificação para o Microsoft Teams parou de funcionar em 22 de maio, com a constatação seca de que a Microsoft finalmente desativou o canal de webhooks obsoleto. Do lado de quem instalou não mudou nada, e a mensagem simplesmente parou de chegar. É o cenário exato de quem monta uma esteira de avisos com URL colada e esquece dela.
O caminho de hoje passa pelo aplicativo Workflows, que roda sobre o Power Automate. Você abre o canal, escolhe um modelo de fluxo que responde a uma requisição de webhook, salva e copia a URL gerada. A partir daí, um POST com {"text": "..."} já publica no canal, e quem quer um cartão formatado envia um Adaptive Card, com type igual a message e o conteúdo dentro de attachments. O Microsoft Learn cita dois números que importam para automação: o payload não pode passar de 28 KB e mais de quatro requisições por segundo derrubam a conexão do cliente até a janela reabrir.
Existe uma pegadinha organizacional que não aparece nos limites técnicos, e ela pesa em agência. O fluxo criado no Workflows pertence a uma pessoa, não ao time nem ao canal. Se o dono sai da empresa e ninguém foi nomeado coproprietário, o fluxo fica órfão e o aviso do cliente para de sair sem que ninguém tenha mexido em nada. A documentação da Microsoft recomenda que administradores adicionem coproprietários justamente para manter a continuidade. Faça isso no dia da criação, não no dia em que o aviso sumir.
Um gatilho, três contratos, três relógios diferentes
Juntando o que cada plataforma pede para a mesma frase de aviso:
- No Discord, uma URL secreta por canal, corpo com
contentouembeds, resposta vazia em caso de sucesso e teto de 2.000 caracteres no texto simples. - No Telegram, um token que vale para todas as conversas do bot, o
chat_idde cada grupo, teto de 4.096 caracteres e escapes obrigatórios se a formatação for MarkdownV2. - No Teams, uma URL gerada por um fluxo do Power Automate que pertence a um usuário, payload de até 28 KB e no máximo quatro requisições por segundo.
Um blog que publica todo dia gera 30 eventos por mês, e escrever o disparo à mão para os três canais multiplica por três a superfície que precisa ser vigiada, cada uma com o seu próprio calendário de mudança. O caso do Teams mostra o formato dessa conta: a mudança não veio de quem publica, veio da plataforma, anunciada em um blog de desenvolvedores que ninguém acompanha.
Neste blog, os avisos de Discord e Telegram saem pelo próprio Post Ping, que detecta a publicação sem passo extra para quem escreve e manda o embed com imagem, cor e link para o canal do Discord e a mensagem para o grupo do Telegram. Existe ainda uma verificação diária que procura posts publicados que não foram notificados, que é a rede de proteção para o dia em que a plataforma responde erro no minuto exato da publicação. O Teams não está entre os canais cobertos; ali o caminho continua sendo montar o fluxo no Workflows por fora.
Meça o seu caso antes de decidir o que automatizar. Pegue os últimos vinte posts do seu blog pela API REST, compare date_gmt com modified_gmt e conte quantos foram editados depois de publicados. Aqui deram seis em treze. Se o seu número for parecido, o disparo preso ao salvamento já mandou quase metade das mensagens de novo, e o problema é anterior a qualquer discussão sobre qual canal usar.
O Discord aceita 2.000 caracteres, o Telegram 4.096 e o Teams 28 KB. Um evento, três tetos, e nenhuma das três plataformas avisa você quando muda o seu.
