Como se tornar Tech Provider da Meta: guia prático 2026

Se você quer oferecer WhatsApp oficial dentro do seu software, atender empresas com uma estrutura própria ou construir uma operação whitelabel, tornar-se Tech Provider da Meta é uma das rotas possíveis. O processo não é apenas preencher um formulário: você precisa provar que a empresa existe, que o acesso aos dados de terceiros é legítimo e que a integração funciona.

Este guia organiza o caminho do zero à aprovação, sem transformar uma tela específica do painel em regra eterna — os nomes e a ordem visual podem mudar, mas as evidências procuradas continuam bastante parecidas.

Resumo para quem precisa decidir agora

• Tech Provider é o ponto de entrada para empresas de tecnologia que oferecem serviços da WhatsApp Business Platform a outras empresas.
• Você precisa de uma empresa verificável, um app Meta ligado a um portfólio empresarial e uma integração funcional.
• A revisão costuma envolver Business Verification, possível Access Verification e App Review. São análises diferentes.
• Para o App Review, prepare vídeos objetivos para as permissões whatsapp_business_messaging e whatsapp_business_management.
• Um produto funcional e testável importa mais que uma apresentação bonita. Cliente pagante não deve ser tratado como requisito universal, mas a Meta pode pedir evidências ou acessos adicionais.
• Em setembro de 2026, novos projetos devem implementar Embedded Signup v4. A versão 2 tem encerramento anunciado para 15 de outubro de 2026.
• Se você precisa começar a vender antes de concluir toda essa estrutura, pode operar com um provedor já preparado, como a SimplesDesk, e amadurecer seu app próprio em paralelo.

Neste guia

• O que muda ao virar Tech Provider
• As três validações
• Passo a passo completo
• Como gravar os vídeos
• Embedded Signup v4
• Checklist final

O que é um Tech Provider

Tech Provider é uma empresa de tecnologia que constrói uma solução de valor agregado sobre a WhatsApp Business Platform e a oferece a outras empresas. Isso pode ser uma caixa de entrada omnichannel, CRM, automação, atendimento com IA, ferramenta de campanhas ou plataforma whitelabel.

Com a configuração e os acessos aprovados, o produto pode:

• integrar clientes por meio do Embedded Signup;
• enviar mensagens em nome das empresas conectadas;
• acessar e gerenciar recursos autorizados de suas WABAs, como números e templates;
• receber mensagens e eventos por webhook;
• administrar a experiência sem obrigar o cliente a executar todo o processo manualmente.

Usar a Cloud API para a sua própria empresa e oferecer uma solução para contas de terceiros são cenários diferentes. O segundo exige permissões avançadas e controles compatíveis com uma operação multiempresa.

Tech Provider, Tech Partner e Solution Partner

• Tech Provider: estágio operacional de entrada para fornecer tecnologia e serviços de WhatsApp a clientes.
• Tech Partner: evolução do Tech Provider que atende critérios adicionais do programa e pode receber reconhecimento e incentivos. A qualificação não deve ser tratada como automática ou garantida.
• Solution Partner: categoria com atribuições comerciais adicionais, incluindo a possibilidade de estender linha de crédito e administrar faturamento em nome do cliente.

Uma empresa também pode trabalhar em conjunto com um Solution Partner. Essa alternativa reduz parte da complexidade operacional para quem ainda não quer manter toda a estrutura sozinho.

A jornada completa

A melhor forma de evitar retrabalho é montar as provas na ordem certa. Primeiro você torna a empresa verificável. Depois configura o app, conclui as validações disponíveis no painel, demonstra as permissões e só então inicia a operação com clientes.

As três validações que costumam confundir

1. Business Verification: a empresa existe?

A Meta confere os dados jurídicos e a relação entre a pessoa que solicita o acesso e a empresa. Razão social, endereço, telefone, site e domínio precisam contar a mesma história.

2. Access Verification: o acesso é legítimo?

Essa validação pode aparecer conforme a configuração e os recursos usados pelo app. Ela serve para confirmar a atividade da empresa e a necessidade legítima de acessar dados ou ativos de outras empresas. Não substitui o App Review.

3. App Review: o produto usa cada permissão corretamente?

Aqui a avaliação sai do papel e entra no produto. Para cada permissão solicitada, você explica a finalidade e mostra uma ação real. O resultado esperado é o Advanced Access necessário para operar em nome de clientes.

Importante: o painel muda com frequência. Se a sua tela usar outro rótulo ou apresentar as etapas em ordem diferente, siga a pendência exibida no app. O objetivo desta separação é ajudar você a entender o que precisa provar, não reproduzir cada botão do painel.

Checklist de pré-requisitos

Não prometa datas internamente antes de a verificação terminar. A Meta não oferece um prazo único garantido, e pedidos adicionais de documento ou uma nova rodada de vídeo aumentam o tempo.

Passo a passo: do zero à submissão

Passo 1 — alinhe empresa, domínio e documentos

Antes de criar o app, compare:

1. razão social e nome da empresa;
2. endereço completo;
3. telefone e e-mail corporativo;
4. domínio do site;
5. dados exibidos no rodapé, política de privacidade e termos.

Diferenças simples — abreviação no endereço, nome fantasia usado como razão social ou domínio sem relação aparente com a empresa — podem gerar pedidos de comprovação.

Na política de privacidade, explique quais dados provenientes do WhatsApp são processados, por que são usados, por quanto tempo ficam armazenados, com quem podem ser compartilhados e como o titular solicita acesso ou exclusão.

Passo 2 — crie e configure o app Meta

No ambiente de desenvolvedores:

1. crie um app adequado para negócios;
2. vincule o portfólio empresarial correto;
3. adicione o caso de uso WhatsApp;
4. preencha nome, ícone, categoria, domínio e e-mail de contato;
5. informe URLs públicas de privacidade, termos e exclusão de dados;
6. configure o webhook e valide o desafio do endpoint.

No fluxo atual, o caminho de Tech Provider costuma aparecer dentro da personalização do caso de uso WhatsApp. Como o painel evolui, procure por Tech Provider onboarding ou pela pendência equivalente mostrada no seu app.

Passo 3 — conclua a verificação da empresa

Prepare documentos legíveis e atualizados. Quando a Meta encontrar a empresa em bases públicas, talvez baste confirmar os dados e o vínculo por e-mail, telefone ou outro método disponível. Quando não encontrar, poderá solicitar documentos.

Antes de enviar:

• não use Gmail ou Hotmail se você possui e-mail no domínio;
• confirme que o site está no ar e explica claramente o produto;
• evite documentos cortados, desfocados ou com dados divergentes;
• mantenha autenticação em dois fatores ativa para os administradores quando solicitada.

Passo 4 — implemente um fluxo ponta a ponta

O mínimo demonstrável deve permitir que uma pessoa veja a cadeia completa:

1. conectar ou selecionar uma conta de WhatsApp;
2. visualizar o número e a WABA vinculados;
3. criar, consultar ou gerenciar um template;
4. enviar uma mensagem;
5. receber a mensagem no aparelho de destino;
6. responder pelo aparelho;
7. ver a resposta e os estados de entrega no produto.

Uma interface completa de CRM ajuda, mas não é o centro da análise. O essencial é provar que o app executa de verdade o uso associado às permissões solicitadas. Em alguns cenários, a própria orientação do painel aceita uma demonstração técnica por ferramentas de API ou pelo WhatsApp Manager; siga exatamente o formato pedido na sua submissão.

Passo 5 — descreva o caso de uso sem frases genéricas

Uma descrição fraca seria:

“Usamos WhatsApp para melhorar a comunicação.”

Uma descrição útil seria:

“Nossa plataforma permite que lojas virtuais conectem a própria conta de WhatsApp, recebam dúvidas em uma caixa compartilhada, enviem atualizações de pedido com templates aprovados e acompanhem os estados de entrega. Solicitamos a permissão de mensagens para enviar e receber comunicações autorizadas e a permissão de gerenciamento para consultar números e administrar templates da empresa conectada.”

Aplique três regras:

• diga quem usa;
• explique qual ação a pessoa executa;
• conecte essa ação à permissão exata solicitada.

Passo 6 — envie o App Review

As permissões normalmente centrais para esse fluxo são:

Não solicite permissões “para usar depois”. Cada item adicional amplia a superfície da revisão e precisa ter justificativa e vídeo próprios.

Cliente em produção: o que a Meta quer de verdade

Não trate “ter um cliente pagante em produção” como requisito universal do App Review. O que precisa existir é uma experiência funcional, coerente com o caso de uso e disponível para avaliação.

Uma configuração segura para a revisão inclui:

• uma conta administradora de demonstração;
• uma WABA e um número próprios ou de teste, quando compatíveis com o fluxo;
• mensagens reais passando pela API;
• templates visíveis;
• webhook recebendo eventos;
• credenciais válidas caso o formulário solicite acesso.

Ao mesmo tempo, não prometa que uma conta demo sempre será suficiente. A Meta pode pedir esclarecimentos, documentos, nova evidência ou acesso adicional conforme o app e a permissão. O objetivo é deixar o caminho reproduzível sem expor dados de clientes reais.

Como gravar um screencast que faz sentido

Grave um vídeo curto por permissão, a menos que o formulário permita e deixe claro que uma demonstração única é suficiente. O revisor precisa saber o que observar sem adivinhar.

Roteiro prático

1. Contexto: mostre a URL, faça login na conta demo e diga qual permissão será demonstrada.
2. Origem da ação: mostre o botão ou a tela que inicia o uso da permissão.
3. Ação real: crie o template, conecte a conta ou envie a mensagem.
4. Resultado externo: mostre a mensagem chegando ao WhatsApp de destino.
5. Retorno: responda e mostre o evento recebido no produto.
6. Conclusão: aponte o status ou dado que comprova que a operação terminou.

O que evitar

• apresentação de slides no lugar do produto;
• cortes que escondem a ação principal;
• texto ou cursor pequenos demais;
• ambiente quebrado, carregando indefinidamente ou com credencial expirada;
• narrar uma função que não aparece na tela;
• misturar várias permissões sem explicar qual está sendo demonstrada;
• usar dados pessoais ou conversas reais de clientes.

Você não precisa transformar o vídeo em propaganda. Clareza vale mais que produção cinematográfica.

Embedded Signup v4: o que mudou

O Embedded Signup é a interface em que o cliente autentica, autoriza o app e cria ou seleciona os ativos necessários para conectar o WhatsApp ao seu produto.

Em setembro de 2026, a implementação recomendada para projetos novos é a versão 4. A descontinuação da versão 2 está anunciada para 15 de outubro de 2026. Se sua integração ainda usa a v2, trate a migração como prioridade e confirme o cronograma no painel antes de publicar mudanças.

No fluxo técnico, seu produto normalmente:

1. abre o Facebook Login for Business com a configuração correta;
2. recebe o código e os identificadores gerados no fluxo;
3. troca o código no servidor e armazena os dados com segurança;
4. assina o app nos eventos da WABA;
5. registra e configura o número conforme o cenário;
6. roteia mensagens e estados recebidos pelo webhook.

Cuidados que aparecem depois da demonstração

• isole os dados de cada cliente;
• criptografe credenciais sensíveis e planeje rotação e revogação;
• deduplique eventos recebidos mais de uma vez;
• valide assinaturas e origem das chamadas ao webhook;
• acompanhe qualidade, restrições e estados dos números;
• defina como o cliente desconecta ou transfere a operação;
• registre ações administrativas para auditoria.

Motivos comuns de reprovação

O vídeo não prova a permissão

Mostrar uma tela pronta não prova que a ação ocorreu. Exiba o início, o processamento e o resultado.

O caso de uso é genérico

“Plataforma de comunicação” não informa usuário, ação nem finalidade. Seja específico.

A política não explica dados do WhatsApp

Uma política genérica não demonstra como mensagens, contatos, mídias e metadados são tratados.

A conta demo não funciona

Teste o login em janela anônima, confira permissões e deixe dados suficientes para o revisor entender a tela.

O produto só envia

Para um produto de atendimento, mostre também recebimento, webhook e exibição da resposta.

Foram pedidas permissões demais

Solicite apenas o que o produto usa agora. “Planejamos usar no futuro” não é uma boa justificativa.

FAQ: erros de rejeição no App Review e como corrigir

Reuni aqui os erros que mais aparecem nas devolutivas. Clique no erro para ver por que acontece e como corrigir antes de reenviar.

“O vídeo não mostra como o app usa a permissão”

Por que acontece: o screencast mostra telas prontas, mas não a ação acontecendo — o clique no envio, a chegada da mensagem, a resposta aparecendo.

Como corrigir: regrave seguindo o roteiro de seis cenas deste guia. Para cada permissão, mostre início, processamento e resultado, sem cortes nas ações críticas. Se pediu whatsapp_business_messaging, o envio e o recebimento precisam aparecer funcionando; se pediu whatsapp_business_management, mostre a gestão de templates ou da conta.

“Não conseguimos acessar o app com as credenciais fornecidas”

Por que acontece: login quebrado, senha expirada, verificação em duas etapas, ambiente fora do ar ou a conta demo sem os dados necessários para a tela fazer sentido.

Como corrigir: antes de reenviar, teste o acesso em uma janela anônima, como um estranho faria: entre com a conta demo, confirme que não há 2FA, que o ambiente está no ar e que a conta tem conversas, templates e histórico suficientes para o revisor entender o produto. Deixe a URL exata de login nas instruções.

“O caso de uso descrito não corresponde ao que foi demonstrado”

Por que acontece: a descrição fala de um fluxo e o vídeo mostra outro — ou a descrição é genérica demais (“plataforma de comunicação”) para o revisor saber o que esperar.

Como corrigir: escreva o caso de uso no formato “quem usa → o que faz → para quê”, e alinhe o vídeo a ele, cena por cena. Exemplo: “Empresas de varejo usam o produto para responder clientes que iniciam conversa no WhatsApp; o vídeo mostra a recepção da mensagem, a resposta do atendente e o registro no histórico.”

“A política de privacidade não descreve o tratamento dos dados do WhatsApp”

Por que acontece: política genérica, copiada de modelo, sem mencionar mensagens, contatos, mídias, metadados, retenção e compartilhamento.

Como corrigir: inclua uma seção específica sobre a integração com o WhatsApp Business Platform: quais dados trafegam, por quanto tempo ficam armazenados, com quem são compartilhados (ex.: a Meta, como provedora do canal) e como o titular pede exclusão. Publique em URL pública e confirme que o link cadastrado no app abre essa página.

“O app só demonstra envio de mensagens”

Por que acontece: o vídeo mostra o disparo, mas um produto de atendimento precisa provar o ciclo completo.

Como corrigir: inclua o caminho de volta: a resposta do cliente chegando pelo webhook e aparecendo na caixa de entrada do atendente, com status de entrega e leitura. Se o produto tem histórico ou relatório, mostre rapidamente no encerramento.

“Permissões solicitadas sem justificativa”

Por que acontece: pedido de permissões que o produto não usa hoje, com justificativa do tipo “planejamos usar no futuro”.

Como corrigir: remova do pedido tudo o que não aparece em uso no vídeo. Solicite apenas o conjunto mínimo para o fluxo demonstrado. Permissões novas podem ser pedidas depois, em uma nova análise, quando a funcionalidade existir.

“A verificação da empresa foi reprovada ou está pendente”

Por que acontece: divergência entre o nome legal, o endereço ou o site cadastrados e os documentos enviados; ou documentos ilegíveis/vencidos.

Como corrigir: confira caractere por caractere o nome legal e o endereço no painel com o que consta no documento oficial. O site precisa estar no ar, com o nome da empresa visível. Reenvie documentos legíveis e dentro da validade. Sem a verificação concluída, a análise do app não avança.

“O fluxo de onboarding não está conforme”

Por que acontece: o produto pede token manual ao cliente ou usa uma versão antiga do Embedded Signup.

Como corrigir: implemente o Embedded Signup na versão vigente, de modo que o cliente autorize o acesso pela janela oficial da Meta e volte ao produto já conectado. Se você usa a versão 2, planeje a migração antes de 15 de outubro de 2026.

Reprovou mesmo assim: e agora?

Leia a devolutiva no painel do app até o fim — ela indica a permissão e o motivo. Corrija apenas o que foi apontado, regrave as evidências afetadas e reenvie. Evite reenviar sem mudanças: submissões repetidas com o mesmo problema não aceleram nada e podem atrasar as próximas análises.

Quanto tempo demora

Não existe SLA público único para concluir tudo. Como referência de planejamento, reserve semanas, não dias. Uma empresa com documentos consistentes e produto pronto tende a avançar mais rápido; pedidos de documentos, falhas na demo e novas rodadas de vídeo aumentam o prazo.

Em vez de prometer uma data, organize o projeto por marcos:

• empresa verificada;
• app configurado;
• integração ponta a ponta testada;
• vídeos e textos revisados;
• primeira resposta da análise;
• correções solicitadas;
• acessos aprovados e teste com o primeiro cliente.

Checklist final antes de enviar

Empresa e presença digital

• [ ] Razão social, endereço, telefone e domínio estão consistentes
• [ ] Site descreve o produto real e possui HTTPS
• [ ] Política de privacidade cobre dados do WhatsApp
• [ ] Termos e exclusão de dados estão acessíveis

App e integração

• [ ] App correto está vinculado ao portfólio correto
• [ ] Caso de uso WhatsApp está configurado
• [ ] Webhook responde e recebe eventos
• [ ] Envio e recebimento foram testados
• [ ] Templates podem ser criados ou consultados
• [ ] Embedded Signup usa a versão atual aplicável

Revisão

• [ ] Cada permissão tem justificativa específica
• [ ] Cada vídeo mostra ação e resultado
• [ ] Nenhum dado real de cliente aparece na gravação
• [ ] Conta demo funciona em janela anônima
• [ ] Instruções de acesso são curtas e reproduzíveis
• [ ] Uma pessoa de fora conseguiu seguir o fluxo sem ajuda

Depois da aprovação

A aprovação não encerra o trabalho; ela inicia a responsabilidade operacional. Antes de acelerar as vendas:

1. teste o Embedded Signup com uma conta que não participou do desenvolvimento;
2. monitore erros de onboarding, webhook e envio;
3. crie alertas para qualidade e restrições dos números;
4. documente revogação, desconexão e recuperação de acesso;
5. mantenha política de privacidade e termos alinhados ao produto;
6. acompanhe alterações de versão e requisitos no painel da Meta.

A evolução para Tech Partner depende dos critérios vigentes do programa. Evite vender selo, listagem ou incentivos como consequência garantida da aprovação como Tech Provider.

Construir tudo agora ou começar com uma estrutura pronta?

Ter um app próprio faz sentido quando controle técnico, marca, integrações e escala justificam o investimento contínuo em engenharia e conformidade. Mas não é obrigatório começar por aí.

A SimplesDesk permite iniciar uma operação de atendimento, automação e WhatsApp oficial com uma base já preparada. Assim, você valida mercado, conquista clientes e aprende o fluxo real antes de assumir sozinho toda a infraestrutura de Tech Provider.

Conheça a SimplesDesk e comece sua operação

Perguntas frequentes

Preciso ter um cliente pagante antes de solicitar o App Review?

Não trate isso como requisito universal. Prepare um produto funcional, uma conta de teste e evidências reproduzíveis. A Meta pode solicitar informações adicionais conforme o app.

Posso demonstrar com uma WABA própria?

Em muitos cenários, uma conta controlada pela própria empresa é adequada para demonstrar envio, recebimento e gestão sem expor clientes. Siga o que o formulário do seu app pedir.

Preciso mostrar uma interface completa?

Não necessariamente. Você precisa provar o uso da permissão de forma clara. Quando o painel aceitar uma demonstração técnica por ferramenta de API ou WhatsApp Manager, siga essa orientação.

Business Verification e App Review são a mesma coisa?

Não. A primeira valida a empresa. A segunda avalia como o app usa as permissões. A verificação de acesso, quando exibida, é uma análise separada sobre a legitimidade do acesso.

O Embedded Signup v2 ainda pode ser usado?

Ele tem encerramento anunciado para 15 de outubro de 2026. Projetos novos devem usar a versão atual, e integrações antigas precisam planejar a migração.

Ser Tech Provider me torna Tech Partner automaticamente?

Não trate a evolução como garantida. Tech Partners atendem critérios adicionais do programa, que podem mudar.

Posso começar sem ter meu próprio app aprovado?

Sim. Você pode operar com a infraestrutura de um provedor ou Solution Partner já preparado e desenvolver seu app próprio em paralelo.

---

Última atualização: 14 de setembro de 2026. Os nomes das telas, critérios e versões podem mudar; confirme as pendências exibidas no painel do seu app antes de submeter.