Treze artigos sa\u00edram deste blog entre 19 de agosto e 1\u00ba de setembro de 2026, os quatro \u00faltimos com intervalo de praticamente 24 horas entre um e outro. Dentro do WordPress, cada um deles foi um evento s\u00f3: um post que mudou de estado. O trabalho aparece depois, quando esse evento \u00fanico precisa virar mensagem em canais que n\u00e3o combinaram nada entre si: o Discord aceita quase o texto cru, o Telegram cobra aten\u00e7\u00e3o na pontua\u00e7\u00e3o e o Teams desligou em maio a porta que todo mundo usava, derrubando quem n\u00e3o tinha migrado.<\/p>\n
Acompanhamos o mesmo aviso saindo pelos tr\u00eas, com a documenta\u00e7\u00e3o oficial de cada plataforma aberta hoje e os dados deste blog na m\u00e3o. Quem nunca configurou um desses gatilhos encontra a explica\u00e7\u00e3o de base em o que \u00e9 um webhook<\/a>.<\/p>\n D\u00e1 para conferir isso em qualquer blog sem abrir o painel: a API REST do WordPress devolve Prender o disparo ao salvamento do post significa mandar seis mensagens repetidas em treze publica\u00e7\u00f5es, sem contar autosave e revis\u00e3o, que passam pelo mesmo caminho. O que interessa \u00e9 a transi\u00e7\u00e3o de estado: o post saiu de rascunho, agendado ou pendente e chegou em publicado. O WordPress entrega essa transi\u00e7\u00e3o com o estado anterior e o novo lado a lado, e a compara\u00e7\u00e3o entre os dois \u00e9 a trava inteira. Se o estado anterior j\u00e1 era publicado, n\u00e3o \u00e9 publica\u00e7\u00e3o nova, \u00e9 edi\u00e7\u00e3o, e ningu\u00e9m precisa ser avisado de novo.<\/p>\n O caso agendado \u00e9 o que mais quebra implementa\u00e7\u00e3o caseira. Um post que vai ao ar \u00e0s sete da manh\u00e3 de domingo muda de estado dentro do cron do WordPress, sem navegador aberto, sem requisi\u00e7\u00e3o de ningu\u00e9m. Se o disparo depende de algo que s\u00f3 existe durante a edi\u00e7\u00e3o no painel, o artigo publica e o aviso n\u00e3o sai. Teste exatamente esse cen\u00e1rio 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.<\/p>\n Dos tr\u00eas canais, o Discord \u00e9 o de menor cerim\u00f4nia. A documenta\u00e7\u00e3o da plataforma \u00e9 expl\u00edcita quanto a isso: os webhooks n\u00e3o exigem um usu\u00e1rio bot nem autentica\u00e7\u00e3o para funcionar. O envio \u00e9 um O corpo precisa trazer pelo menos um entre Em caso de sucesso, o Discord devolve Quando o limite aparece, vem um Seis dos treze posts foram editados depois de j\u00e1 estarem no ar<\/h2>\n
date_gmt<\/code>, a hora da publica\u00e7\u00e3o, e modified_gmt<\/code>, a da \u00faltima altera\u00e7\u00e3o. Neste blog, seis dos treze artigos t\u00eam o segundo campo maior que o primeiro. Em tr\u00eas deles a diferen\u00e7a passa de 37 horas: o texto ficou no ar quase dois dias antes de algu\u00e9m voltar e corrigir alguma coisa.<\/p>\nO Discord aceita quase o texto cru<\/h2>\n
POST<\/code> para \/webhooks\/{webhook.id}\/{webhook.token}<\/code>, e o segredo \u00e9 a pr\u00f3pria URL. Quem tem a URL manda mensagem no canal, o que tamb\u00e9m define o tamanho do estrago se ela vazar em um reposit\u00f3rio p\u00fablico.<\/p>\ncontent<\/code>, embeds<\/code>, components<\/code>, file<\/code> e poll<\/code>. Para um aviso de artigo novo, os dois primeiros bastam. O campo content<\/code> aceita at\u00e9 2.000<\/strong> caracteres, e cada mensagem comporta at\u00e9 10<\/strong> embeds, aquele bloco com barra colorida na lateral onde cabem t\u00edtulo, descri\u00e7\u00e3o, imagem e link.<\/p>\n204 No Content<\/code>, sem corpo nenhum: a mensagem entrou e voc\u00ea n\u00e3o recebe o identificador dela. Se o seu c\u00f3digo precisa guardar esse id para editar ou apagar o aviso depois, o envio tem que ir com wait=true<\/code> na query, e a\u00ed a resposta vira 200<\/code> com o objeto da mensagem. Trocar um pelo outro no meio do caminho \u00e9 o tipo de mudan\u00e7a que quebra um integrador silenciosamente, porque o envio continua funcionando e s\u00f3 o p\u00f3s-processamento para.<\/p>\n429<\/code> com um corpo JSON que traz retry_after<\/code>, o n\u00famero de segundos a esperar antes de tentar de novo. Junto v\u00eam os cabe\u00e7alhos X-RateLimit-Remaining<\/code> e X-RateLimit-Reset-After<\/code>, que dizem quanto sobrou e quando a janela reabre. O teto global documentado \u00e9 de 50<\/strong> requisi\u00e7\u00f5es por segundo, folgad\u00edssimo para quem publica um artigo por dia. O risco real \u00e9 outro: requisi\u00e7\u00f5es inv\u00e1lidas repetidas contam em um balde separado, e chegar a 10.000 delas em 10 minutos rende restri\u00e7\u00e3o tempor\u00e1ria de IP. Um la\u00e7o que insiste em uma URL de webhook apagada chega l\u00e1 sozinho. O significado de cada c\u00f3digo de resposta est\u00e1 destrinchado em erro de webhook no WordPress<\/a>.<\/p>\nO Telegram troca o segredo de lugar e cobra pela pontua\u00e7\u00e3o<\/h2>\n