Por que o token da Meta expirou de novo, se ningu\u00e9m trocou senha e ningu\u00e9m tocou na conex\u00e3o? Na maior parte dos casos ele n\u00e3o expirou: foi invalidado. S\u00e3o dois eventos diferentes, com causas diferentes, e a Graph API devolve a mesma palavra para os dois.<\/p>\n
Expirar \u00e9 rel\u00f3gio. Um token de curta dura\u00e7\u00e3o vale, segundo a documenta\u00e7\u00e3o de login da Meta, cerca de uma a duas horas; um token de longa dura\u00e7\u00e3o vale cerca de 60 dias<\/strong>. Invalidar \u00e9 evento: a Meta encerra a sess\u00e3o que gerou o token e ele morre no meio do prazo, ou sem prazo nenhum. O token de P\u00e1gina, que \u00e9 o que a maioria dos sites acaba guardando, n\u00e3o tem data de validade. Ele ainda assim para de funcionar, e \u00e9 a\u00ed que come\u00e7a a procura por uma resposta que a mensagem de erro n\u00e3o d\u00e1.<\/p>\n Sobre o token de P\u00e1gina, obtido a partir de um token de usu\u00e1rio de longa dura\u00e7\u00e3o, a letra da documenta\u00e7\u00e3o \u00e9 esta: \u201cn\u00e3o tem data de expira\u00e7\u00e3o e s\u00f3 expira ou \u00e9 invalidado sob certas condi\u00e7\u00f5es\u201d. Sobre o token de usu\u00e1rio de sistema, usado por integra\u00e7\u00f5es de neg\u00f3cio: \u201ctokens de longa dura\u00e7\u00e3o que n\u00e3o expiram com base no tempo\u201d, com a ressalva de que continuam \u201csujeitos a invalida\u00e7\u00e3o por outros motivos\u201d. Nenhum dos dois tem prazo, e os dois caem.<\/p>\n A pr\u00f3pria p\u00e1gina avisa que esses n\u00fameros n\u00e3o s\u00e3o contrato: \u201cn\u00e3o dependa de que esses tempos de vida permane\u00e7am os mesmos, eles podem mudar sem aviso ou expirar mais cedo\u201d. Quem construiu uma rotina em cima de \u201crenova a cada 55 dias e est\u00e1 resolvido\u201d descobre isso no dia em que o token cai no dia 12.<\/p>\n As condi\u00e7\u00f5es de invalida\u00e7\u00e3o est\u00e3o listadas na p\u00e1gina de depura\u00e7\u00e3o e tratamento de erros, e s\u00e3o quatro na pr\u00e1tica: a pessoa saiu do Facebook, a pessoa trocou a senha, a pessoa removeu a autoriza\u00e7\u00e3o do aplicativo, ou aconteceu um evento de seguran\u00e7a. A quarta est\u00e1 escrita assim: \u201cdevido a eventos relacionados \u00e0 seguran\u00e7a, tokens de acesso podem ser invalidados antes do tempo de expira\u00e7\u00e3o esperado\u201d. \u00c9 uma frase curta que cobre um universo grande de coisas que acontecem do lado da Meta, sem aviso e sem explica\u00e7\u00e3o individual.<\/p>\n Essa distin\u00e7\u00e3o decide o que fazer. Token que expirou por tempo se resolve com rotina de renova\u00e7\u00e3o. Token invalidado por evento n\u00e3o se resolve com rotina nenhuma: exige que algu\u00e9m autorize de novo, e o \u00fanico ganho poss\u00edvel \u00e9 descobrir isso em minutos em vez de descobrir numa segunda-feira, quando tr\u00eas artigos j\u00e1 deixaram de sair.<\/p>\n O diagn\u00f3stico come\u00e7a por saber o que est\u00e1 gravado no banco. Existem tr\u00eas caminhos comuns, e cada um tem um comportamento de validade pr\u00f3prio:<\/p>\n Esse terceiro caminho tem uma renova\u00e7\u00e3o pr\u00f3pria, e as regras dela s\u00e3o espec\u00edficas o bastante para quebrar quando a rotina \u00e9 ing\u00eanua. A chamada \u00e9 A frase que fecha essa se\u00e7\u00e3o da documenta\u00e7\u00e3o \u00e9 a que mais custa caro: \u201ctokens que n\u00e3o foram renovados em 60 dias v\u00e3o expirar e n\u00e3o poder\u00e3o mais ser renovados\u201d. N\u00e3o existe janela de car\u00eancia. Um token que passou do prazo n\u00e3o volta com Guardar token de usu\u00e1rio quando se poderia guardar token de P\u00e1gina \u00e9 o erro de desenho mais comum, e ele transforma um problema que n\u00e3o tinha prazo em um problema que tem 60 dias.<\/p>\n O c\u00f3digo 190 \u00e9 o guarda-chuva: token de acesso expirado, com a orienta\u00e7\u00e3o oficial de obter um token novo. Sozinho ele n\u00e3o diz nada de \u00fatil. O que diz \u00e9 o subc\u00f3digo que vem junto.<\/p>\n O Fora da faixa do 190, dois c\u00f3digos aparecem no mesmo contexto e confundem. O O Ler o subc\u00f3digo antes de agir economiza o ciclo inteiro de tentativa e erro. A mesma l\u00f3gica vale para os erros que aparecem depois, na hora de publicar, e que t\u00eam uma lista pr\u00f3pria de c\u00f3digos: j\u00e1 escrevemos sobre como ler o subc\u00f3digo de um erro de publica\u00e7\u00e3o no Instagram<\/a>, que \u00e9 o passo seguinte quando o token est\u00e1 bom e o post mesmo assim n\u00e3o entra.<\/p>\n Existe uma frase que todo mundo que integra com a Meta encontra cedo ou tarde: \u201cError validating access token: The session has been invalidated because the user changed their password or Facebook has changed the session for security reasons.\u201d A leitura natural \u00e9 parar na primeira metade e ir perguntar ao cliente se ele trocou a senha.<\/p>\n No f\u00f3rum de desenvolvedores da Meta, uma das discuss\u00f5es sobre essa mensagem foi aberta justamente por quem j\u00e1 tinha checado isso: a conta n\u00e3o trocava de senha havia seis meses e o erro apareceu do mesmo jeito. A resposta marcada como solu\u00e7\u00e3o aponta para a segunda metade da frase, a parte do \u201cou o Facebook mudou a sess\u00e3o por motivos de seguran\u00e7a\u201d. A causa foi a invalida\u00e7\u00e3o autom\u00e1tica, n\u00e3o a senha.<\/p>\n Outra discuss\u00e3o no mesmo f\u00f3rum mostra a escala em que isso acontece. Um desenvolvedor relatou ter perdido o token de cerca de 10% dos usu\u00e1rios conectados, entre 700 e 800 pessoas, e fez a pergunta \u00f3bvia: \u00e9 plaus\u00edvel que 700 pessoas tenham trocado a senha? A perda foi gradual, descoberta ao consultar m\u00eddias, e os tokens eram de longa dura\u00e7\u00e3o obtidos pelo caminho documentado. A ferramenta de depura\u00e7\u00e3o mostrava a expira\u00e7\u00e3o como \u201c0 (Never)\u201d.<\/p>\n Quem escreveu o pr\u00f3prio script de publica\u00e7\u00e3o herda tr\u00eas tarefas que n\u00e3o aparecem no dia em que o script come\u00e7a a funcionar: renovar o acesso dentro da janela, detectar a invalida\u00e7\u00e3o que chega fora dela e avisar algu\u00e9m que consiga autorizar de novo. No Post Ping, a conex\u00e3o \u00e9 feita pelo login oficial do Facebook e a renova\u00e7\u00e3o do acesso roda por conta do plugin, sem ningu\u00e9m copiar token nem colar identificador de P\u00e1gina. E o token fica criptografado no banco do pr\u00f3prio site, n\u00e3o em servidor nosso, o que muda quem precisa confiar em quem. A base disso \u00e9 a mesma para qualquer integra\u00e7\u00e3o s\u00e9ria: publicar pela Graph API oficial, o caminho descrito em publicar do WordPress no Instagram e no Facebook automaticamente<\/a>.<\/p>\n H\u00e1 um segundo rel\u00f3gio rodando junto, e ele n\u00e3o \u00e9 de token, \u00e9 de permiss\u00e3o. Se o aplicativo n\u00e3o usa uma permiss\u00e3o por 90 dias, em geral por inatividade da pessoa, a documenta\u00e7\u00e3o \u00e9 direta: a pessoa precisa conceder aquela permiss\u00e3o de novo. E a renova\u00e7\u00e3o autom\u00e1tica dos SDKs oficiais tem a mesma fronteira, descrita assim na p\u00e1gina de tokens de longa dura\u00e7\u00e3o: o SDK renova o token automaticamente \u201cse a pessoa usou seu aplicativo nos \u00faltimos 90 dias\u201d.<\/p>\n Para um site que publica todo dia, esses 90 dias nunca chegam. Para um blog que publica uma vez por m\u00eas, ou para a conta de um cliente que ficou parada entre dois contratos, esse prazo \u00e9 o gatilho mais prov\u00e1vel de quebra, e a ordem dos acontecimentos esconde o aviso: primeiro a conta fica quieta, depois a permiss\u00e3o precisa ser concedida outra vez, e s\u00f3 ent\u00e3o algu\u00e9m tenta publicar e descobre.<\/p>\n Combine isso com a regra do Instagram e o buraco fica vis\u00edvel. A renova\u00e7\u00e3o exige token v\u00e1lido e n\u00e3o expirado, com pelo menos 24 horas de vida. Um token que ficou 61 dias sem uso n\u00e3o \u00e9 renov\u00e1vel, e nenhuma rotina de retentativa resolve. A janela real de manobra \u00e9 o intervalo entre o primeiro dia \u00fatil do token e o dia 60, e quem s\u00f3 olha para o token quando uma publica\u00e7\u00e3o falha est\u00e1 sempre olhando depois da janela.<\/p>\n Para ag\u00eancias, o item que some da planilha n\u00e3o \u00e9 o tempo de renovar vinte tokens. \u00c9 o tempo de descobrir qual dos vinte caiu, em qual conta, e de alcan\u00e7ar a pessoa que tem papel naquela P\u00e1gina para autorizar de novo, que costuma ser a mesma pessoa que n\u00e3o responde no fim de semana.<\/p>\n O endpoint A resposta traz Por isso Uma verifica\u00e7\u00e3o di\u00e1ria desse endpoint, guardando Tr\u00eas escolhas reduzem a frequ\u00eancia dessas quedas, e nenhuma elimina o problema. A primeira \u00e9 guardar token de P\u00e1gina em vez de token de usu\u00e1rio sempre que a publica\u00e7\u00e3o for em P\u00e1gina ou em conta profissional do Instagram ligada a ela: sai do rel\u00f3gio de 60 dias e passa a depender s\u00f3 de evento. A segunda \u00e9 usar um usu\u00e1rio de sistema do portf\u00f3lio de neg\u00f3cios, cujo token n\u00e3o expira com base no tempo. Tem uma condi\u00e7\u00e3o que derruba metade das tentativas: o usu\u00e1rio de sistema e o aplicativo precisam pertencer ao mesmo neg\u00f3cio, e a documenta\u00e7\u00e3o tamb\u00e9m separa o usu\u00e1rio de sistema administrador, que cria outros e distribui permiss\u00f5es, do usu\u00e1rio de sistema comum, que s\u00f3 acessa o que foi explicitamente concedido.<\/p>\n A terceira \u00e9 aceitar que a integra\u00e7\u00e3o tem manuten\u00e7\u00e3o de vers\u00e3o, n\u00e3o s\u00f3 de token. A Graph API v26.0 foi publicada em 29 de julho de 2026, e o calend\u00e1rio de vers\u00f5es d\u00e1 a cada uma cerca de dois anos at\u00e9 a desativa\u00e7\u00e3o: a v24.0 saiu em outubro de 2025 e est\u00e1 marcada para fevereiro de 2028; a v25.0 saiu em fevereiro de 2026 e vai at\u00e9 julho de 2028. Um token perfeitamente v\u00e1lido numa vers\u00e3o desativada devolve erro do mesmo jeito, e o time vai passar o primeiro dia inteiro investigando o token errado.<\/p>\n Esse trabalho n\u00e3o 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\u00e7\u00e3o. Para quem vai manter em casa, o desenho da conex\u00e3o est\u00e1 descrito passo a passo na documenta\u00e7\u00e3o do Post Ping<\/a>, e serve de refer\u00eancia mesmo para quem prefere escrever o pr\u00f3prio c\u00f3digo.<\/p>\n","protected":false},"excerpt":{"rendered":" Token da Meta expirado quase nunca venceu por tempo. O que diz o subc\u00f3digo do erro 190, os 90 dias de inatividade e a chamada que avisa antes da queda.<\/p>\n","protected":false},"author":1,"featured_media":168,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-169","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-publicacao-automatica"],"_links":{"self":[{"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/posts\/169","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/comments?post=169"}],"version-history":[{"count":0,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/posts\/169\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/media\/168"}],"wp:attachment":[{"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/media?parent=169"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/categories?post=169"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/postping.com.br\/blog\/wp-json\/wp\/v2\/tags?post=169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Expirar por tempo e ser invalidado n\u00e3o s\u00e3o a mesma coisa<\/h2>\n
Qual token o seu site guarda muda a resposta inteira<\/h2>\n
\n
GET oauth\/access_token<\/code> com grant_type=fb_exchange_token<\/code>, mais o identificador e o segredo do aplicativo. Vale cerca de 60 dias e \u00e9 o que mais aparece em integra\u00e7\u00e3o feita \u00e0s pressas.<\/li>\nGET {app-scoped-user-id}\/accounts<\/code> usando o token de usu\u00e1rio de longa dura\u00e7\u00e3o. N\u00e3o tem data de validade, e a pessoa que pede precisa ter um papel na P\u00e1gina.<\/li>\napi.instagram.com\/oauth\/access_token<\/code>, que se troca por um de 60 dias em graph.instagram.com\/access_token<\/code> com grant_type=ig_exchange_token<\/code>.<\/li>\n<\/ul>\ngraph.instagram.com\/refresh_access_token<\/code> com grant_type=ig_refresh_token<\/code>. O token enviado precisa ter pelo menos 24 horas de vida, precisa estar v\u00e1lido e n\u00e3o expirado, e a permiss\u00e3o instagram_business_basic<\/code> precisa estar concedida. O token devolvido vale 60 dias contados da renova\u00e7\u00e3o, n\u00e3o do dia em que foi criado.<\/p>\nrefresh_access_token<\/code>, volta s\u00f3 com algu\u00e9m clicando em autorizar outra vez.<\/p>\nO 190 e o subc\u00f3digo que diz qual foi a causa<\/h2>\n
463<\/code> \u00e9 expira\u00e7\u00e3o de fato, o caso do rel\u00f3gio. O 467<\/code> \u00e9 token inv\u00e1lido, que na documenta\u00e7\u00e3o aparece como revogado ou invalidado, e \u00e9 o subc\u00f3digo t\u00edpico do evento de seguran\u00e7a. O 460<\/code> \u00e9 troca de senha. O 458<\/code> \u00e9 aplicativo n\u00e3o instalado, ou seja, a autoriza\u00e7\u00e3o foi removida, e a orienta\u00e7\u00e3o \u00e9 reautenticar. O 459<\/code> e o 464<\/code> mandam a pessoa entrar no Facebook pela web ou pelo aplicativo para resolver alguma pend\u00eancia de conta. O 492<\/code> \u00e9 sess\u00e3o inv\u00e1lida no sentido de permiss\u00e3o: a pessoa n\u00e3o tem o acesso necess\u00e1rio na P\u00e1gina associada.<\/p>\n102<\/code> trata de sess\u00e3o de API com credencial expirada ou revogada, e os subc\u00f3digos s\u00e3o os mesmos de cima. O 10<\/code> \u00e9 permiss\u00e3o negada: a permiss\u00e3o n\u00e3o foi concedida ou foi removida, o que n\u00e3o \u00e9 problema de token e sim de escopo. Trocar o token nesse caso n\u00e3o muda nada, porque o token est\u00e1 v\u00e1lido e simplesmente n\u00e3o pode fazer aquilo.<\/p>\n492<\/code> merece um par\u00e1grafo pr\u00f3prio porque a causa dele costuma ser humana. O token de P\u00e1gina s\u00f3 \u00e9 emitido para quem tem papel na P\u00e1gina, e ele acompanha essa pessoa. Quando quem autorizou sai da empresa, perde o cargo de administrador ou \u00e9 removido do portf\u00f3lio de neg\u00f3cios do cliente, o token para de valer sem que ningu\u00e9m tenha mexido em integra\u00e7\u00e3o nenhuma. Para ag\u00eancia, esse \u00e9 o dia em que o setup feito pelo estagi\u00e1rio de dois anos atr\u00e1s vira um problema de n\u00edvel de acesso, n\u00e3o de c\u00f3digo.<\/p>\nA mensagem que culpa a senha e quase nunca \u00e9 a senha<\/h2>\n
Os 90 dias que ningu\u00e9m anota no calend\u00e1rio<\/h2>\n
debug_token responde antes de o erro aparecer<\/h2>\n
graph.facebook.com\/debug_token<\/code> recebe dois par\u00e2metros e responde por qualquer token guardado: input_token<\/code>, o token investigado, e access_token<\/code>, a credencial com que voc\u00ea pergunta.<\/p>\nis_valid<\/code>, expires_at<\/code>, data_access_expires_at<\/code>, issued_at<\/code>, o tipo do token e a lista de escopos. Os dois campos de data s\u00e3o diferentes e \u00e9 comum trat\u00e1-los como um s\u00f3: expires_at<\/code> \u00e9 quando o token deixa de funcionar, data_access_expires_at<\/code> \u00e9 quando o acesso aos dados daquela pessoa precisa ser reconcedido. O segundo \u00e9 o campo que materializa a regra dos 90 dias, e ele vence mesmo em token que, no primeiro campo, n\u00e3o vence nunca.<\/p>\nexpires_at<\/code> igual a zero n\u00e3o \u00e9 garantia de nada. Foi exatamente o que o desenvolvedor do f\u00f3rum viu, \u201c0 (Never)\u201d, pouco antes de perder 700 tokens de uma vez. O campo que responde \u00e0 pergunta que interessa \u00e9 is_valid<\/code>, e ele s\u00f3 responde se algu\u00e9m perguntar.<\/p>\nis_valid<\/code> e as duas datas, custa uma requisi\u00e7\u00e3o por conta por dia e muda o momento da descoberta. Em vez de o cliente avisar que o post n\u00e3o saiu, o alerta chega enquanto o token ainda est\u00e1 de p\u00e9 e ainda d\u00e1 para renovar dentro da janela.<\/p>\nO desenho que quebra menos vezes<\/h2>\n