No fim deste guia, um artigo publicado no seu WordPress aparece na Página do Facebook sem que você tenha criado aplicativo nenhum no painel de desenvolvedor da Meta e sem ter enviado nada para revisão. O caminho é oficial, usa a mesma Graph API de quem mantém app próprio, e a única coisa que muda é de quem é o aplicativo que assina o pedido.
Decida em qual das duas rotas você está
Todo pedido à Graph API sai de algum aplicativo registrado na Meta, então a escolha nunca é entre ter app e não ter: é entre o app ser seu ou ser de quem te vende a integração. Quem registra o próprio app cai na régua de níveis de acesso, e ela é mais dura do que parece na primeira leitura.
A documentação de níveis de acesso diz que permissões em Standard Access só podem ser pedidas a usuários que tenham um papel no aplicativo que está pedindo. Na prática: você cria o app, conecta a sua Página, funciona; o sócio tenta conectar a Página dele e recebe erro, porque ele não é desenvolvedor nem testador do seu app. Para sair disso é preciso Advanced Access, e aí a Meta exige verificação de negócio, escrito sem meio-termo na própria documentação: Business Verification é obrigatória para obter Advanced Access, e em alguns casos ainda há revisão individual por permissão.
A página de verificação de negócio acrescenta duas informações que pegam agência desprevenida. Desde 1º de fevereiro de 2023, um app que precise de acesso avançado pode ter que concluir a verificação. E só alguém com papel de administrador no Business consegue concluir o processo, o que significa documento de empresa, não de pessoa física. Depois de aprovado, o app com Advanced Access ainda passa pelo Data Use Checkup uma vez por ano para continuar valendo.
A rota do app próprio tem um ganho concreto, e ele não é técnico. O WP2Social Auto Publish, com mais de 9 mil instalações ativas, responde no próprio FAQ por que obriga o usuário a criar o aplicativo: assim o post não sai com a atribuição do tipo shared via apontando para o app de outra pessoa. Se a sua marca aparece no rodapé de cada publicação e isso importa para o cliente, o custo da verificação se justifica. Se ninguém nunca reparou nesse rodapé, você está pagando semanas de burocracia por um detalhe que o seu público não vê.
A rota oposta já está documentada com essas palavras em plugin público. O Arrow Publisher responde no FAQ que não exige app de desenvolvedor próprio porque usa um serviço central de conexão para o OAuth do Facebook, e descreve o que acontece depois: o token da Página escolhida fica guardado no site em forma criptografada. Essas duas frases descrevem o desenho de qualquer integração dessa rota, e são as duas perguntas a fazer para quem te vender uma: de quem é o app, e onde fica o token.
Quando essa etapa falha, o sintoma é sempre o mesmo: a conexão funciona para uma pessoa e para mais ninguém. Antes de abrir chamado, olhe em qual nível o app está. Se estiver em Standard Access e você não pretende verificar o negócio agora, a saída provisória é dar papel de desenvolvedor ou testador no app a quem precisa conectar, sabendo que isso não escala para clientes.
Garanta o papel certo na Página antes de clicar em conectar
Nenhum aplicativo de terceiro resolve essa etapa por você. A documentação da Pages API é direta: para conseguir um token de um usuário, esse usuário precisa ser dono da Página ou conseguir executar uma task nela. A task que interessa para publicar chama-se CREATE_CONTENT, descrita como publicar na Página.
Papel no aplicativo e papel na Página são coisas separadas. Dá para ser administrador do app e não conseguir publicar em Página nenhuma, e dá para ser o dono da Página e ainda assim receber uma lista vazia se o login foi feito com o perfil errado. Quem administra várias contas de cliente costuma ter dois perfis abertos no mesmo navegador, e o login do Facebook pega o que estiver ativo.
A verificação dessa etapa é uma chamada só. Depois de autorizar, o app consulta /me/accounts, que devolve o id e o token de acesso de cada Página que aquele usuário liberou. Se a resposta vem com a lista vazia, pare ali: nenhuma etapa seguinte vai funcionar. As causas mais comuns são o perfil errado no login, a Página pertencer a um portfólio empresarial em que você recebeu acesso a métricas mas não a publicação, ou a permissão de listagem não ter sido concedida na tela de consentimento.
Quando a etapa dá certo, o que você ganha é um tipo de credencial diferente da que entrou. Um token de usuário de longa duração dura cerca de 60 dias, segundo a documentação de tokens da Meta. O token de Página obtido a partir dele não tem data de validade e só expira ou é invalidado sob certas condições, nas palavras da mesma página. Na rotina de quem mantém o site, isso quer dizer que a conexão não cai por calendário, cai por evento: troca de senha, remoção de papel na Página, revisão de permissões do lado do usuário. Se a sua já caiu antes, os gatilhos estão destrinchados em token da Meta expirado raramente é um prazo que venceu.
Autorize as três permissões que o feed da Página exige
A referência do endpoint de feed da Página lista o que precisa estar concedido para o POST ser aceito, além do token de Página pedido por alguém com a task de criar conteúdo:
pages_show_list, que permite ao app enumerar as Páginas que você administra e é o que alimenta a lista de escolha;pages_manage_posts, que autoriza criar, editar e apagar publicações em nome da Página;pages_read_engagement, que dá leitura do conteúdo e das métricas da Página, e sem a qual o próprio pedido de publicação é recusado.
A tela de consentimento da Meta separa permissão de ativo. A pessoa pode conceder as três permissões e, na etapa seguinte, marcar só uma das cinco Páginas que administra. O resultado é uma conexão que parece completa em qualquer verificação superficial e falha na hora de publicar em uma Página específica.
Para confirmar sem adivinhar, inspecione o token no endpoint /debug_token?input_token={token}. Ele devolve is_valid, scopes com a lista de permissões concedidas, granular_scopes com o recorte por ativo e profile_id, que no caso de um token de Página indica a qual Página aquele token pertence. É em granular_scopes que a Página esquecida aparece como ausente, enquanto scopes segue mostrando as três permissões concedidas.
Quando o diagnóstico apontar ativo faltando, refaça o login e, na tela em que a Meta pergunta a quais Páginas o app terá acesso, marque a Página certa. Repetir a autorização não duplica nada: a concessão anterior é substituída pela nova.
Publique o primeiro post e confirme que ele existe
O endpoint é POST /{page-id}/feed, e a documentação exige que pelo menos um entre message e link seja enviado. Para quem está distribuindo artigo, os dois fazem sentido juntos: message carrega o texto que vai aparecer no feed e link aponta para a URL do artigo, que é o que faz o Facebook montar o cartão de pré-visualização com título e imagem.
No primeiro disparo, mande published como false. O endpoint aceita esse parâmetro, que por padrão vem verdadeiro, e cria a publicação sem colocá-la no feed. Você confere o texto, o link e o cartão dentro das ferramentas de publicação da Página, e só depois repete a chamada valendo. A alternativa é testar ao vivo e deixar três posts de teste visíveis para quem seguiu a Página nesta semana.
Fixe a versão da API na URL da chamada em vez de usar o caminho sem versão. A v26.0 foi lançada em 29 de julho de 2026 e é a mais recente listada no changelog; a v25.0, de 18 de fevereiro de 2026, tem validade anunciada até 29 de julho de 2028. Esses dois anos de sobrevida são o seu intervalo para migrar com calma, e você só tem esse intervalo se souber em qual versão o seu código está.
Manter isso funcionando à mão significa guardar token no banco do site, tratar renovação e acompanhar changelog. Quem prefere não manter usa uma conexão pronta: o Post Ping abre o login oficial da Meta, descobre a Página e a conta sozinho, sem pedir que você gere token ou copie id em lugar nenhum, e renova o acesso por conta própria. O detalhe de cada recurso está em recursos do plugin, e a esteira inteira, do artigo publicado ao post no ar, está em publicar do WordPress no Instagram e no Facebook automaticamente.
Feita a primeira publicação, três leituras dizem se a integração está de pé.
A primeira é a resposta da própria chamada. Uma publicação aceita devolve um objeto com o campo id. Guarde esse id no banco junto com o artigo: é ele que permite, meses depois, saber se aquele post saiu e qual é. Sem esse registro, a única forma de auditar é abrir a Página e rolar o feed.
A segunda é o token, um dia depois de publicar. Chame /debug_token de novo e leia is_valid. Uma conexão que publicou hoje e amanhã responde com token inválido não quebrou por acaso: alguém mexeu em senha, em papel na Página ou nas permissões do app.
A terceira mora no cabeçalho da resposta, e quase ninguém olha. Pedidos da Pages API feitos com token de Página trazem o cabeçalho X-Business-Use-Case-Usage, com call_count em porcentagem do permitido e estimated_time_to_regain_access em minutos, para o caso de você já estar bloqueado. O teto sai da fórmula que a Meta publica: 4800 chamadas em 24 horas multiplicadas pelo número de usuários engajados da Página. Página nova, com pouco engajamento, tem teto baixo, e é por isso que a primeira semana de uma automação é a mais arriscada. Se call_count já sobe acima de 20% publicando um artigo por dia, tem chamada sobrando em algum laço do seu código. Estourado o limite, a Graph API responde 80001 quando o pedido saiu com token de Página, e 32 quando saiu com token de app ou de usuário. Os dois códigos significam bloqueio por volume, mas apontam para contadores diferentes, e tratar um pelo outro leva você a otimizar o laço errado.
