Aprovação de app na Meta (App Review)

Publicar fotos e vídeos orgânicos no feed de uma conta profissional do Instagram exige a permissão de publicação de conteúdo do Instagram — a documentação de content publishing da Meta hoje a nomeia como instagram_business_content_publish. Algumas integrações e documentações mais antigas ainda citam instagram_content_publish; a Meta já trocou nomes de permissão antes sem muito aviso, então vale checar as duas em vez de assumir que uma foi definitivamente aposentada. Se você também publica na Página do Facebook vinculada, precisa separadamente de pages_manage_posts. Cada uma é revisada e concedida de forma independente — passar na revisão de uma não concede a outra.

Antes de submeter qualquer coisa, confirme os nomes exatos de permissão na referência de permissões da Meta. Peça só o que a sua funcionalidade já publicada de fato usa — os revisores checam o uso contra o pedido, e pedir mais do que você usa é um dos motivos mais comuns de reprovação.

Um revisor humano abre o seu app do jeito que um usuário real abriria: precisa conseguir fazer login, chegar até a funcionalidade que usa a permissão e ver que ela faz exatamente o que a sua descrição de caso de uso diz que faz. Se o revisor não conseguir acessar ou reproduzir o fluxo com as próprias credenciais de teste, a submissão inteira é reprovada — não só a permissão em questão.

Duas coisas são checadas em paralelo: a sua descrição de caso de uso (o propósito declarado bate com o que a permissão realmente serve) e o seu screencast (a gravação prova isso). A configuração do app — URL de política de privacidade, ícone do app, categoria, marcações de uso de dados — é validada antes de qualquer humano olhar a sua submissão; configuração incompleta causa reprovação imediata.

As diretrizes de gravação de tela da Meta pedem imagens que mostrem como testar cada permissão ou funcionalidade solicitada — na prática isso significa gravar um vídeo separado por permissão em vez de juntar várias num só, já que um revisor testando uma permissão não deveria precisar avançar o vídeo passando por um fluxo que não tem nada a ver com aquilo. Cada clipe deve mostrar, em ordem: o passo de login ou conexão de conta, a funcionalidade específica que aciona a permissão e evidência clara de que o dado ou a ação resultante é usada só para o propósito descrito. Pular o login, começar já autenticado ou passar por cima da tela de consentimento são motivos de reprovação por si só.

Higiene prática importa mais que produção caprichada: resolução completa, cursor visível, interface em inglês (ou legendas, se não for) e um fluxo que o revisor conseguiria repetir com uma conta de teste nova. Não peça uma permissão para uma funcionalidade que ainda não foi construída — os revisores precisam ver ela funcionando, não descrita.

Em ordem decrescente de frequência, aproximadamente: um screencast vago ou incompleto (passos faltando, consentimento pouco claro, a permissão não demonstrada de fato); um caso de uso que não bate com a permissão pedida (por exemplo, pedir acesso de publicação para descrever uma funcionalidade só de analytics); configuração de app faltando ou desalinhada (URL de política de privacidade, categoria, declarações de uso de dados); pedir permissões que o seu produto já publicado não precisa no momento; e instruções de teste que o revisor não consegue seguir — credenciais erradas, ambiente de staging quebrado ou passos que assumem contexto que o revisor não tem.

Nada disso é exótico. A maioria das reprovações são falhas de processo, não disputas de política — o que é uma boa notícia, porque são corrigíveis apertando a submissão em vez de reenviar a mesma evidência e torcer.

A Meta não publica uma garantia fixa de prazo, e o número real varia: já foi relatado de poucos dias, para uma submissão limpa e bem preparada, a várias semanas em períodos de alto volume — e desenvolvedores relatam que a ponta mais lenta vem se tornando mais comum ao longo do tempo. Cada permissão é revisada no próprio ritmo — pedir publicação no Instagram e na Página juntas não significa que as duas saem ao mesmo tempo. Monte o seu plano de lançamento em cima da ponta mais lenta do que você está vendo agora, não do caso mais rápido que já ouviu falar, e reserve tempo para pelo menos uma rodada de reprovação e reenvio, que é comum mesmo em apps bem preparados.

Como o relógio só começa a contar quando a configuração do app está completa e o screencast foi enviado, a alavanca mais rápida que você controla é a preparação: um ambiente de staging funcionando, uma política de privacidade finalizada e um screencast filmado em cima da submissão real, não um rascunho que você planeja refazer depois.

Confirme os nomes de permissão atuais na documentação da Meta, já que eles mudaram antes e vão mudar de novo. Garanta que a funcionalidade está totalmente construída e acessível por uma conta nova, sem papel especial. Escreva instruções de teste que um estranho conseguiria seguir sem contexto prévio. Grave um screencast focado por permissão. E deixe a URL da política de privacidade, o ícone do app e as marcações de uso de dados completos antes de clicar em enviar — isso sozinho elimina uma categoria inteira de reprovações instantâneas.

Enquanto espera a revisão, você não precisa travar o desenvolvimento: o modo sandbox do PostGate roda o ciclo completo de publicação — validação, entrega assíncrona, status por destino, webhooks — sem chamar um provedor real, para você construir e testar o resto da sua integração em paralelo com o relógio de revisão da Meta.