Quando se fala em automatizar redes sociais, a conversa costuma parar em "postar todo dia às 9h" ou "deixar a IA escrever o texto".
Mas o difícil de verdade não é o botão de postar.
Distribuir só os artigos certos. Não postar duas vezes. Não deixar tudo parar porque um serviço caiu. Não forçar a passagem por um CAPTCHA. Passar para uma pessoa só o que só uma pessoa pode fazer. E, depois de distribuir, usar o resultado para mudar a próxima distribuição.
Só quando tudo isso se encaixa dá para dizer que a distribuição está automatizada.
Se você lida com 12 idiomas, várias redes sociais e até newsletter, a distribuição deixa de ser um recurso de agendamento de posts. Vira um pequeno sistema distribuído.
1. O objetivo não é "totalmente sem gente": é "pessoas tratam só as exceções"
Se a meta da automação for "ninguém encosta em nada", o projeto desanda.
Os serviços externos reais têm CAPTCHA para confirmar que você é uma pessoa, verificação por SMS, autenticação em dois fatores (2FA), verificação de identidade, aceite expresso dos termos de uso, revisão de apps de desenvolvedor... Isso não é defeito. É um limite que o serviço colocou de propósito: "aqui só passa o próprio titular".
Então a forma final é esta:
Geração do artigo → Checagem de qualidade → Versão de cada idioma → Publicação em produção → Releitura do HTML de produção → Candidato à distribuição → Texto de cada idioma → Redes sociais e newsletter → Coleta de resultados → Decisão da próxima distribuição
Se no meio do caminho aparecer algo que só uma pessoa resolve, entrega-se para ela só aquele caso.
Por exemplo, se só o X em japonês pediu CAPTCHA, só o X em japonês espera. Não precisa deixar o Bluesky em inglês, o Facebook em francês, a newsletter, a análise de acessos e a geração do próximo artigo todos sentados de castigo.
Não precisa os 12 idiomas ficarem de luto por causa de um único CAPTCHA.
Produtos de fluxo de trabalho durável (durable workflow), como o Cloudflare Workflows, também são pensados para manter estado por muito tempo, repetir etapas que falharam e esperar eventos externos ou aprovação humana. O importante não é usar um produto específico, e sim tratar a espera por uma pessoa como um estado do sistema, e não como uma parada.
2. Separe "o artigo ficou pronto" de "já pode distribuir"
Se você ligar a camada de distribuição direto à geração de artigos, fica fácil dar problema.
O Markdown foi salvo. A tradução terminou. O build passou.
Nenhuma dessas coisas garante que "o leitor consegue abrir essa URL agora e ler direito".
Por isso a unidade distribuível não é o nome do artigo, e sim
articleId × locale × contentSha
E nas redes sociais, vai-se além:
articleId × locale × contentSha × platform × campaignType
O importante aqui é o contentSha. Mesmo com a mesma URL, se o texto foi atualizado, é outra revisão. Um post criado para o texto antigo não pode ser lançado como anúncio do texto novo.
E a condição para passar algo para a distribuição não é "está no GitHub", e sim ter relido e confirmado o HTML de produção daquele locale e daquele contentSha.
O que a porta de entrada da postagem automática precisa saber não é "tem rascunho?", e sim "existe um produto pronto que o leitor pode abrir agora?".
3. Timeout não é igual a falha: errar aqui gera posts gêmeos
O que dá medo nas APIs externas não são os erros claros, e sim os ambíguos.
Você enviou o post para a API. Do seu lado deu timeout. Sem resposta.
Nessa hora, se você pensar:
"Parece que falhou. Vou mandar de novo",
e o primeiro envio na verdade tinha dado certo, nascem dois posts iguais.
"A API não respondeu, então por garantia postei o mesmo artigo três vezes" é a história de terror da automação.
O Cloudflare Queues adota por padrão a entrega at-least-once (pelo menos uma vez), e em casos raros a mesma mensagem pode ser entregue mais de uma vez. Por isso a documentação oficial também recomenda eliminar duplicatas com um ID único ou uma chave de idempotência (idempotency key).
Então cria-se uma chave determinística para cada envio:
sha256(articleId + locale + contentSha + platform + campaignType)
Na tabela de recibos, essa chave é UNIQUE.
Diante de um timeout, em vez de reenviar na hora, a ordem é:
- Conferir o registro de recibos
- Se der para reler do lado do provedor, conferir se já foi postado
- Tentar de novo só se ficar confirmado que não foi postado
A fila (Queue) não é "mágica que executa exatamente uma vez". O projeto está em fazer o resultado convergir para uma única vez mesmo com duplicatas.
4. Falhas devem ficar presas no "menor escopo", não no "sistema inteiro"
O maior desperdício na automação é promover um erro isolado a pane geral.
No mínimo, o domínio de falha (failure domain) é dividido em
platform × locale × account
Se a autenticação do X em japonês expirou, só ele fica BLOCKED.
Se o Bluesky em inglês devolveu 429, só ele vai para RETRY_WAIT.
Se uma página do Facebook espera verificação de identidade, só ela vai para HUMAN_ACTION_REQUIRED.
Os outros seguem funcionando.
Os estados também não podem ser só "sucesso / falha". Representa melhor a realidade dividir em algo como:
- READY
- ACTIVE
- DEGRADED_BUT_RUNNING
- HUMAN_ACTION_REQUIRED
- BLOCKED_PROVIDER
- RETRY_WAIT
- DISABLED_BY_POLICY
Se de 15 linhas no total 14 funcionam e só uma espera por uma pessoa, o estado geral não é "tudo parado". Está mais para DEGRADED_BUT_RUNNING.
Contra o 429, força de vontade não adianta. Se há Retry-After, obedeça. Para 5xx, backoff exponencial com limite. Para 401/403, se existe um caminho legítimo de renovação de credencial, repare uma vez; se mesmo assim não resolver, pare só aquela conta.
CAPTCHA e verificação humana não entram em loop de repetição automática. Não existe API que vire humana depois de 100 tentativas.
5. A Human Handoff Queue deve ser uma ordem de serviço, não um "socorro"
Se o mecanismo de passar o trabalho para pessoas for descuidado, sobra uma montanha de trabalho manual no fim da automação.
Uma passagem ruim é assim:
"As redes estão paradas. Por favor, verifique."
Verificar o quê? Onde? Só o login? Precisa mudar configuração? E o que fazer depois?
Uma passagem boa traz, no mínimo, para cada caso:
- platform
- locale
- account
- blockerType
- horário de detecção
- horário em que dá para tentar de novo
- URL a abrir
- o que a pessoa deve fazer
- o que a pessoa não deve fazer
- o que o sistema automático vai conferir de novo depois
- o escopo que esse bloqueio interrompe
- se dá para continuar o restante do trabalho
Por exemplo:
"Entre na conta oficial deste idioma e conclua apenas o CAPTCHA exibido. Não altere as configurações de postagem nem o perfil. Depois, na próxima ronda, o sistema relê o estado de autenticação e retoma a partir de um post de teste (canary)."
Assim dá para entender de primeira.
E o ponto importante: não se automatiza a resolução do CAPTCHA.
Usar solver, falsificar o desafio, contornar por vias não oficiais: isso não é automação, é ir na direção de romper o limite que o outro lado definiu.
As pessoas saem da tarefa diária de postar e assumem apenas o limite que a máquina não consegue atravessar de forma legítima.
Senhas, tokens OAuth de acesso e de atualização, cookies de sessão, códigos SMS/2FA, códigos de recuperação e segredos de API privados não ficam no GitHub nem nos logs comuns. No GitHub fica só o que não é secreto e é necessário para retomar: o handle público, o estado, o erro tratado (sanitized), o ID do recibo, a URL pública do post etc.
6. Não misture postagem automática com bot de engajamento
Uma conta oficial postar automaticamente artigos do próprio site é um assunto; automatizar curtidas, seguir, responder e até mensagens diretas é outro.
As Automation Rules do X, na versão de abril de 2026, permitem postagens automáticas úteis e informativas que sigam as regras, mas proíbem driblar os limites de taxa (rate limit) da API, automação sem API que manipula o site por script e postagens de spam ou duplicadas. Curtidas automáticas também são proibidas.
Por isso, os valores iniciais podem ser bem sóbrios:
- AUTO_PUBLISH = true
- AUTO_LIKE = false
- AUTO_FOLLOW = false
- AUTO_UNFOLLOW = false
- AUTO_REPLY = false
- AUTO_DM = false
Primeiro, restrinja a responsabilidade a "entregar corretamente os artigos oficiais".
O Bluesky também permite criar posts pela API oficial, e cada post pode carregar informação de idioma. Ou seja, numa operação multilíngue, o mais natural é alinhar texto e metadados de idioma de cada locale, em vez de mandar o texto em inglês para todo lugar.
A automação de navegador fica limitada a apoiar situações como a configuração inicial de contas, em que não há API oficial ou a operação humana é permitida. Para a distribuição de rotina, apoie-se o máximo possível em APIs oficiais e autenticação oficial.
Os canais iniciais se definem por locale, por exemplo: ja→X, en→X/Bluesky, ko→X, zh-Hans→Weibo, zh-Hant→Facebook/Threads, es・pt-BR・id・th・vi・fr→Facebook, de→Facebook/X. Superfícies centradas em imagem e vídeo, como Instagram, TikTok e Reels, ficam para uma segunda etapa, depois que a geração de cartões e o controle de qualidade de mídia (media QA) estiverem estáveis. As APIs, políticas de automação e termos de uso de cada plataforma precisam ser reconferidos sempre no momento da implementação.
7. Operar em 12 idiomas não é um "torneio de tradução de posts em japonês"
Nos sites multilíngues há um acidente comum.
Traduziu o artigo japonês para 12 idiomas. Criou um único texto de rede social em japonês. Traduziu esse texto para 11 idiomas. Pronto.
Assim, o sentido de ter vertido o texto principal para 12 idiomas fica fraco.
O texto do post é feito lendo o corpo realmente publicado naquele locale, como se a conta oficial do site naquele idioma soltasse um comentário.
A forma básica é curta:
Essa é aquela coisa chata que dá mais trabalho do que parece. 🫠 URL
ou então,
Dá pra automatizar isso também? 👀 URL
Não precisa de resumo longo nem de "imperdível", "chocante" ou "confira agora". E fabricar um falso depoimento, como se um terceiro tivesse achado o site por acaso e se emocionado, é estranho num post do próprio site.
A personalidade da marca é comum, mas o texto fica natural em cada idioma. Não se finge que são pessoas diferentes que administram as contas.
Além disso, medicina, direito, investimento, grandes quantias de dinheiro, desastres, crimes, mortes, automutilação, violência, abuso sexual, menores de idade, segurança, política e eleições, e conflitos intensos passam para o serious mode.
Nesse caso, em princípio, sem emoji, sem sensacionalismo e sem afirmar mais do que o artigo. Se for um artigo político, não se acrescenta apoio (endorsement) automaticamente.
O "modo piada total" não é uma configuração universal. Num artigo sobre ambulância não precisa de 🫠.
8. Newsletter não é a "versão por e-mail das redes": é a mesma filosofia de distribuição em outro adaptador
A newsletter também não deve ser enviada direto da geração do texto.
No mínimo, guarde
- explicit opt-in
- locale
- topics
- consentAt
- status
- unsubscribeAt
- createdAt
e não envie o mesmo artigo várias vezes.
O e-mail de contato e o sistema de envio em massa também ficam logicamente separados.
Para as respostas dos leitores dá para usar o canal de contato atual, mas a base de envio deve ser um adaptador que possa ser trocado depois por um provedor dedicado.
O Gmail exige de quem envia em grande volume autenticação de envio, evitar spam e e-mails não solicitados, e um mecanismo fácil de cancelamento, e trata o cancelamento como requisito importante nas mensagens de assinatura.
O cancelamento de assinatura não é "provavelmente para no próximo lote": a pessoa sai imediatamente da lista de envio.
O valor de uma newsletter não é juntar endereços. É entregar a informação que o leitor pediu, na frequência que ele pediu, e deixá-lo sair na hora em que quiser.
9. Se o KPI for "curtida", você acaba construindo uma máquina que corre atrás de curtida
Ao incluir melhoria automática, o que você coloca como função objetivo é decisivo.
Se você maximizar só as curtidas das redes, ganham os títulos mais apelativos, as afirmações extremas e os assuntos que beiram a polêmica.
Mas o que um site de artigos realmente quer é outra coisa.
A prioridade pode ser, por exemplo:
- site visit
- meaningful reading
- next article
- return visit
- newsletter signup
Ou seja, dá-se mais peso a "a pessoa veio ao site por esse post?", "leu de verdade?", "foi para o próximo artigo?" e "voltou?".
As campanhas de distribuição também se dividem em
- NEW
- UPDATED
- TRENDING
- POPULAR
- EVERGREEN
Não se repete o post com "grande atualização!" só porque se corrigiu uma letra. UPDATED é só para atualizações relevantes (material update).
Para POPULAR e TRENDING, se já existe uma medição real de acessos, reaproveite-a. Não é preciso criar um ranking de popularidade separado para a distribuição e deixar dois números brigando.
O horário de distribuição também não se decide por um preconceito como "é japonês, então às 20h", e sim explorando o locale × country × platform × weekday × hour reais. No começo, teste vários horários (slots) e, quando houver dados acumulados, concentre.
10. Na prática: não é "postar", é fazer o estado avançar
A operação real fica mais clara se pensada como uma sequência de transições de estado.
- O artigo do locale alvo é publicado em produção.
- O HTML de produção do contentSha exato é relido e marcado como PRODUCTION_VERIFIED.
- Cria-se o candidato à distribuição com articleId × locale × contentSha × platform × campaignType.
- Lê-se o texto desse locale e gera-se um post curto.
- Verificam-se a proibição de hype, o serious mode, o tamanho, a URL e o idioma.
- Entra na outbox com a idempotency key.
- Envia-se pela API oficial do provedor.
- Além do recibo da API, se possível, relê-se o post público.
- Coletam-se visitas ao site, leitura completa, próximo artigo e retorno.
- Usa-se isso na próxima decisão entre NEW / UPDATED / TRENDING / POPULAR / EVERGREEN.
Se no meio aparecer um CAPTCHA, só aquele escopo vai para HUMAN_ACTION_REQUIRED.
Se for 429, para RETRY_WAIT.
Se o provedor estiver fora do ar, para BLOCKED_PROVIDER.
O resto segue em frente.
Também não se dispara de uma vez contra 15 contas desde o início. Para cada adaptador, passe por:
leitura da autenticação (auth readback) → simulação (dry run) → canary com um artigo real → recibo → releitura pública (public readback) → checagem do locale → checagem da supressão de duplicatas → checagem da atribuição na análise de acessos
e só depois amplie.
E a entrada que o operador vê fica reunida num único current-status.
Na implementação, também é mais difícil multiplicar as fontes da verdade se, em vez de criar uma segunda fábrica de artigos e um segundo scheduler para a distribuição, você conecta ao dono de publicação existente como post-publication child (processo filho pós-publicação) depois do PRODUCTION_VERIFIED, reaproveitando o durable runtime e o state store que já existem.
Se, para responder "como está isso agora?", uma pessoa precisar garimpar 15 JSONs e logs, nesse momento a automação está devolvendo o trabalho para a pessoa.
O mais importante na distribuição automática não é "nada falhar".
É, mesmo falhando, saber onde parou, ter um escopo de parada pequeno, entregar às pessoas só o que só elas podem fazer, deixar o resto andar sozinho e, depois da recuperação, continuar de onde parou sem executar nada em dobro.
Sumir com o botão de postar é só o prólogo.
A automação de verdade é automatizar também a operação do dia em que algo dá errado.
