Por que o token da Meta expirou de novo, se ninguém trocou senha e ninguém tocou na conexão? Na maior parte dos casos ele não expirou: foi invalidado. São dois eventos diferentes, com causas diferentes, e a Graph API devolve a mesma palavra para os dois.
Expirar é relógio. Um token de curta duração vale, segundo a documentação de login da Meta, cerca de uma a duas horas; um token de longa duração vale cerca de 60 dias. Invalidar é evento: a Meta encerra a sessão que gerou o token e ele morre no meio do prazo, ou sem prazo nenhum. O token de Página, que é o que a maioria dos sites acaba guardando, não tem data de validade. Ele ainda assim para de funcionar, e é aí que começa a procura por uma resposta que a mensagem de erro não dá.
Expirar por tempo e ser invalidado não são a mesma coisa
Sobre o token de Página, obtido a partir de um token de usuário de longa duração, a letra da documentação é esta: “não tem data de expiração e só expira ou é invalidado sob certas condições”. Sobre o token de usuário de sistema, usado por integrações de negócio: “tokens de longa duração que não expiram com base no tempo”, com a ressalva de que continuam “sujeitos a invalidação por outros motivos”. Nenhum dos dois tem prazo, e os dois caem.
A própria página avisa que esses números não são contrato: “não dependa de que esses tempos de vida permaneçam os mesmos, eles podem mudar sem aviso ou expirar mais cedo”. Quem construiu uma rotina em cima de “renova a cada 55 dias e está resolvido” descobre isso no dia em que o token cai no dia 12.
As condições de invalidação estão listadas na página de depuração e tratamento de erros, e são quatro na prática: a pessoa saiu do Facebook, a pessoa trocou a senha, a pessoa removeu a autorização do aplicativo, ou aconteceu um evento de segurança. A quarta está escrita assim: “devido a eventos relacionados à segurança, tokens de acesso podem ser invalidados antes do tempo de expiração esperado”. É uma frase curta que cobre um universo grande de coisas que acontecem do lado da Meta, sem aviso e sem explicação individual.
Essa distinção decide o que fazer. Token que expirou por tempo se resolve com rotina de renovação. Token invalidado por evento não se resolve com rotina nenhuma: exige que alguém autorize de novo, e o único ganho possível é descobrir isso em minutos em vez de descobrir numa segunda-feira, quando três artigos já deixaram de sair.
Qual token o seu site guarda muda a resposta inteira
O diagnóstico começa por saber o que está gravado no banco. Existem três caminhos comuns, e cada um tem um comportamento de validade próprio:
- Token de usuário de longa duração: sai de
GET oauth/access_tokencomgrant_type=fb_exchange_token, mais o identificador e o segredo do aplicativo. Vale cerca de 60 dias e é o que mais aparece em integração feita às pressas. - Token de Página: sai de
GET {app-scoped-user-id}/accountsusando o token de usuário de longa duração. Não tem data de validade, e a pessoa que pede precisa ter um papel na Página. - Token de usuário do Instagram: no caminho com login do próprio Instagram, o código de autorização vira um token de uma hora em
api.instagram.com/oauth/access_token, que se troca por um de 60 dias emgraph.instagram.com/access_tokencomgrant_type=ig_exchange_token.
Esse terceiro caminho tem uma renovação própria, e as regras dela são específicas o bastante para quebrar quando a rotina é ingênua. A chamada é graph.instagram.com/refresh_access_token com grant_type=ig_refresh_token. O token enviado precisa ter pelo menos 24 horas de vida, precisa estar válido e não expirado, e a permissão instagram_business_basic precisa estar concedida. O token devolvido vale 60 dias contados da renovação, não do dia em que foi criado.
A frase que fecha essa seção da documentação é a que mais custa caro: “tokens que não foram renovados em 60 dias vão expirar e não poderão mais ser renovados”. Não existe janela de carência. Um token que passou do prazo não volta com refresh_access_token, volta só com alguém clicando em autorizar outra vez.
Guardar token de usuário quando se poderia guardar token de Página é o erro de desenho mais comum, e ele transforma um problema que não tinha prazo em um problema que tem 60 dias.
O 190 e o subcódigo que diz qual foi a causa
O código 190 é o guarda-chuva: token de acesso expirado, com a orientação oficial de obter um token novo. Sozinho ele não diz nada de útil. O que diz é o subcódigo que vem junto.
O 463 é expiração de fato, o caso do relógio. O 467 é token inválido, que na documentação aparece como revogado ou invalidado, e é o subcódigo típico do evento de segurança. O 460 é troca de senha. O 458 é aplicativo não instalado, ou seja, a autorização foi removida, e a orientação é reautenticar. O 459 e o 464 mandam a pessoa entrar no Facebook pela web ou pelo aplicativo para resolver alguma pendência de conta. O 492 é sessão inválida no sentido de permissão: a pessoa não tem o acesso necessário na Página associada.
Fora da faixa do 190, dois códigos aparecem no mesmo contexto e confundem. O 102 trata de sessão de API com credencial expirada ou revogada, e os subcódigos são os mesmos de cima. O 10 é permissão negada: a permissão não foi concedida ou foi removida, o que não é problema de token e sim de escopo. Trocar o token nesse caso não muda nada, porque o token está válido e simplesmente não pode fazer aquilo.
O 492 merece um parágrafo próprio porque a causa dele costuma ser humana. O token de Página só é emitido para quem tem papel na Página, e ele acompanha essa pessoa. Quando quem autorizou sai da empresa, perde o cargo de administrador ou é removido do portfólio de negócios do cliente, o token para de valer sem que ninguém tenha mexido em integração nenhuma. Para agência, esse é o dia em que o setup feito pelo estagiário de dois anos atrás vira um problema de nível de acesso, não de código.
Ler o subcódigo antes de agir economiza o ciclo inteiro de tentativa e erro. A mesma lógica vale para os erros que aparecem depois, na hora de publicar, e que têm uma lista própria de códigos: já escrevemos sobre como ler o subcódigo de um erro de publicação no Instagram, que é o passo seguinte quando o token está bom e o post mesmo assim não entra.
A mensagem que culpa a senha e quase nunca é a senha
Existe uma frase que todo mundo que integra com a Meta encontra cedo ou tarde: “Error validating access token: The session has been invalidated because the user changed their password or Facebook has changed the session for security reasons.” A leitura natural é parar na primeira metade e ir perguntar ao cliente se ele trocou a senha.
No fórum de desenvolvedores da Meta, uma das discussões sobre essa mensagem foi aberta justamente por quem já tinha checado isso: a conta não trocava de senha havia seis meses e o erro apareceu do mesmo jeito. A resposta marcada como solução aponta para a segunda metade da frase, a parte do “ou o Facebook mudou a sessão por motivos de segurança”. A causa foi a invalidação automática, não a senha.
Outra discussão no mesmo fórum mostra a escala em que isso acontece. Um desenvolvedor relatou ter perdido o token de cerca de 10% dos usuários conectados, entre 700 e 800 pessoas, e fez a pergunta óbvia: é plausível que 700 pessoas tenham trocado a senha? A perda foi gradual, descoberta ao consultar mídias, e os tokens eram de longa duração obtidos pelo caminho documentado. A ferramenta de depuração mostrava a expiração como “0 (Never)”.
Quem escreveu o próprio script de publicação herda três tarefas que não aparecem no dia em que o script começa a funcionar: renovar o acesso dentro da janela, detectar a invalidação que chega fora dela e avisar alguém que consiga autorizar de novo. No Post Ping, a conexão é feita pelo login oficial do Facebook e a renovação do acesso roda por conta do plugin, sem ninguém copiar token nem colar identificador de Página. E o token fica criptografado no banco do próprio site, não em servidor nosso, o que muda quem precisa confiar em quem. A base disso é a mesma para qualquer integração séria: publicar pela Graph API oficial, o caminho descrito em publicar do WordPress no Instagram e no Facebook automaticamente.
Os 90 dias que ninguém anota no calendário
Há um segundo relógio rodando junto, e ele não é de token, é de permissão. Se o aplicativo não usa uma permissão por 90 dias, em geral por inatividade da pessoa, a documentação é direta: a pessoa precisa conceder aquela permissão de novo. E a renovação automática dos SDKs oficiais tem a mesma fronteira, descrita assim na página de tokens de longa duração: o SDK renova o token automaticamente “se a pessoa usou seu aplicativo nos últimos 90 dias”.
Para um site que publica todo dia, esses 90 dias nunca chegam. Para um blog que publica uma vez por mês, ou para a conta de um cliente que ficou parada entre dois contratos, esse prazo é o gatilho mais provável de quebra, e a ordem dos acontecimentos esconde o aviso: primeiro a conta fica quieta, depois a permissão precisa ser concedida outra vez, e só então alguém tenta publicar e descobre.
Combine isso com a regra do Instagram e o buraco fica visível. A renovação exige token válido e não expirado, com pelo menos 24 horas de vida. Um token que ficou 61 dias sem uso não é renovável, e nenhuma rotina de retentativa resolve. A janela real de manobra é o intervalo entre o primeiro dia útil do token e o dia 60, e quem só olha para o token quando uma publicação falha está sempre olhando depois da janela.
Para agências, o item que some da planilha não é o tempo de renovar vinte tokens. É o tempo de descobrir qual dos vinte caiu, em qual conta, e de alcançar a pessoa que tem papel naquela Página para autorizar de novo, que costuma ser a mesma pessoa que não responde no fim de semana.
debug_token responde antes de o erro aparecer
O endpoint graph.facebook.com/debug_token recebe dois parâmetros e responde por qualquer token guardado: input_token, o token investigado, e access_token, a credencial com que você pergunta.
A resposta traz is_valid, expires_at, data_access_expires_at, issued_at, o tipo do token e a lista de escopos. Os dois campos de data são diferentes e é comum tratá-los como um só: expires_at é quando o token deixa de funcionar, data_access_expires_at é quando o acesso aos dados daquela pessoa precisa ser reconcedido. O segundo é o campo que materializa a regra dos 90 dias, e ele vence mesmo em token que, no primeiro campo, não vence nunca.
Por isso expires_at igual a zero não é garantia de nada. Foi exatamente o que o desenvolvedor do fórum viu, “0 (Never)”, pouco antes de perder 700 tokens de uma vez. O campo que responde à pergunta que interessa é is_valid, e ele só responde se alguém perguntar.
Uma verificação diária desse endpoint, guardando is_valid e as duas datas, custa uma requisição por conta por dia e muda o momento da descoberta. Em vez de o cliente avisar que o post não saiu, o alerta chega enquanto o token ainda está de pé e ainda dá para renovar dentro da janela.
O desenho que quebra menos vezes
Três escolhas reduzem a frequência dessas quedas, e nenhuma elimina o problema. A primeira é guardar token de Página em vez de token de usuário sempre que a publicação for em Página ou em conta profissional do Instagram ligada a ela: sai do relógio de 60 dias e passa a depender só de evento. A segunda é usar um usuário de sistema do portfólio de negócios, cujo token não expira com base no tempo. Tem uma condição que derruba metade das tentativas: o usuário de sistema e o aplicativo precisam pertencer ao mesmo negócio, e a documentação também separa o usuário de sistema administrador, que cria outros e distribui permissões, do usuário de sistema comum, que só acessa o que foi explicitamente concedido.
A terceira é aceitar que a integração tem manutenção de versão, não só de token. A Graph API v26.0 foi publicada em 29 de julho de 2026, e o calendário de versões dá a cada uma cerca de dois anos até a desativação: a v24.0 saiu em outubro de 2025 e está marcada para fevereiro de 2028; a v25.0 saiu em fevereiro de 2026 e vai até julho de 2028. Um token perfeitamente válido numa versão desativada devolve erro do mesmo jeito, e o time vai passar o primeiro dia inteiro investigando o token errado.
Esse trabalho não termina numa tarde: ele volta toda vez que a Meta mexe em alguma coisa, e cada equipe decide se ele fica em casa ou com quem vende a integração. Para quem vai manter em casa, o desenho da conexão está descrito passo a passo na documentação do Post Ping, e serve de referência mesmo para quem prefere escrever o próprio código.
