Meta Tech Provider na prática

Premissas que os outros guias erram

Começamos por aqui porque cada uma dessas custa dias. Todas apareceram em material publicado sobre o assunto, inclusive em coisa que a gente mesmo escreveu antes de conferir.

As duas fases

A ordem não é sugestão. A verificação de empresa trava o App Review, e o App Review trava a Coexistence.

Pré-voo

Editar qualquer dado da empresa durante a análise reinicia a verificação do zero. Publique tudo antes e congele.

• Política de privacidade publicada e linkada. Precisa cobrir Platform Data recebido da Meta, não só dados do seu site
• Site com razão social, CNPJ, endereço e telefone batendo com o que você vai digitar no formulário
• HTTPS válido e zero link quebrado. Site que não carrega é motivo oficial de rejeição
• Nome no Business Manager igual à Razão Social exata. Copie e cole do Cartão CNPJ, com LTDA, pontuação e acento
• E-mail em domínio próprio. Gmail te joga num pedido de prova de domínio que você não satisfaz
• 2FA ligado no Business Manager
• Ícone do app 1024 por 1024, sem verde-WhatsApp e sem balão de fala
• Nome do app sem marca da Meta. Nada de WhatsApp, Meta, FB, Face ou Book
• Cartão CNPJ emitido no dia, CPF tarjado em todos os documentos
• Segundo perfil pessoal como admin de backup do portfólio. Precaução nossa, de higiene de conta: não achamos fonte ligando isso à verificação Sem fonte

Business Verification

O caminho é business.facebook.com/settings/security, botão Iniciar verificação. Se aparecer "Não se qualifica para verificação", o gatilho chega por e-mail vindo de outra plataforma. Siga aquele link.

Documentos aceitos no Brasil

• Conta de consumo serve só para endereço e telefone. A Meta é explícita que ela não prova razão social Oficial
• Documento fiscal preenchido pela própria empresa não é aceito. Precisa ser emitido pelo governo Oficial
• MEI passa. O CCMEI aparece como documento aceito para o Brasil nas listas que BSPs publicam do processo. A Meta não publica a lista por país, então isso vem de terceiro, não da fonte. Quem falha costuma esbarrar em outra coisa, endereço residencial no CCMEI, e-mail gratuito, site ausente, mas essa é leitura nossa dos padrões de recusa, não lista publicada por ninguém Relato
• Português está na lista de idiomas aceitos. Não traduza nada Oficial
• Tarje o CPF. A Meta pede para cobrir informação pessoal que ela não precisa Oficial

Método de confirmação

São cinco: e-mail, telefone, SMS, mensagem do WhatsApp e verificação de domínio. Vale escolher registro TXT de DNS, que não depende de deploy e não some num rebuild do site. A Meta confirma que o registro pode ser removido depois sem afetar o status.

Motivos oficiais de rejeição

• Enviar ou ser suspeito de enviar informações falsas ou enganosas
• Reivindicar portfólio que não é seu ou que você não representa
• Tentar burlar o sistema de análise
• Site que não carrega, sem HTTPS, ou com link que leva a erro

O quarto é o único puramente técnico e o mais fácil de evitar. Também é o mais ignorado.

App Review

Seis componentes, todos obrigatórios: verification, app settings, allowed usage, data handling, data protection e reviewer instructions. Rascunho não é analisado.

Você não precisa do produto pronto

Este é o achado que tira o App Review do caminho crítico.

Circula que a Meta teria escrito, em outra página, que não é preciso esperar pela implementação completa do cadastro incorporado. Procuramos e não achamos essa frase, nem em inglês nem na versão em português, então não a tratamos como oficial. O que sustenta o atalho é o parágrafo acima, esse sim citável, mais o relato de quem virou Tech Provider com zero clientes usando um front montado em poucas horas só para gravar. Relato

Especificação dos vídeos

Roteiro do vídeo A, para whatsapp_business_messaging

• Comece deslogado. Faça login e mostre a tela de autorização com os escopos
• App Dashboard, WhatsApp, API Setup. Adicione um número de teste como destinatário
• Execute o cURL na tela, visível
• Mostre o WhatsApp recebendo a mensagem
• Legenda no momento do envio nomeando a permissão em uso

Roteiro do vídeo B, para whatsapp_business_management

• Comece deslogado, login, tela de autorização
• WhatsApp Manager, criar um template Utility em pt_BR do zero
• Adicionar os botões de resposta rápida
• Submeter e mostrar o status ficando pending

Prazo, com a doc se contradizendo em quatro lugares

O relato de primeira mão é mais útil que os quatro. Timeline printada de um caso real: submeteu às 07:00 e foi reprovado, resubmeteu às 08:21 e foi reprovado, resubmeteu às 10:53 e foi reprovado, aprovado às 03:00 do dia seguinte. Relato

A consequência estratégica é grande: itere rápido em vez de caprichar numa submissão única. O ciclo é curto o bastante para tratar rejeição como retorno, não como desastre.

O atalho que talvez exista

A documentação diz que dá para pular o App Review. Um relato de primeira mão diz que não funciona para Coexistence. Como não dá para resolver isso pela leitura, fica registrado dos dois lados.

O que a doc afirma

Somado a: "while your app is in development mode, these permissions will appear in Embedded Signup's authorization screen to anyone who has an admin, developer, or tester role on your app".

O que o relato afirma

A Coexistence tem uma checagem além da de permissões, que a doc genérica não cobre, e ela é de status de Tech Provider, não de aprovação do app em si. Numa discussão pública do Chatwoot a regra aparece explícita, "You must be a Meta Tech Provider to onboard your existing WhatsApp Business App phone number", e quem abriu o problema confirmou depois: "Managed to get this working after becoming Tech Provider". Ou seja, o relato acima está certo no efeito e impreciso no nome: o que destrava não é o app aprovado, é o credenciamento. Relato

Construção

Arquitetura mínima

Cliente (navegador)
     |  clica em "Conectar WhatsApp"
     v
Página estática HTTPS  --- FB JS SDK, Embedded Signup --->  Meta
(Cloudflare Pages)     <-- code (TTL 30s) + waba_id --------
     |
     v
Business token (never-expire)

Meta --webhooks-->  Cloudflare Worker  -->  seu backend
                    (valida assinatura,
                     responde 200)

Obrigatório hospedar: a página HTTPS, que pode ser estática, e o webhook público. Sem webhook não há sincronização, e portanto não há Coexistence. Não é preciso domínio próprio, servidor persistente nem linha de crédito.

Apps Script não serve como webhook

Web Apps do Apps Script respondem HTTP 302, redirecionando de script.google.com para script.googleusercontent.com. É arquitetural, e não existe API no Apps Script para definir status code. A Meta exige 200 com o hub.challenge cru, e 302 não é 200. Há relatos equivalentes de falha com webhooks de Zoom e de Dropbox. Relato

Worker que funciona

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);

    if (request.method === 'GET') {
      if (url.searchParams.get('hub.mode') === 'subscribe' &&
          url.searchParams.get('hub.verify_token') === env.VERIFY_TOKEN) {
        return new Response(url.searchParams.get('hub.challenge'), {
          status: 200,
          headers: { 'content-type': 'text/plain' },
        });
      }
      return new Response('Forbidden', { status: 403 });
    }

    if (request.method === 'POST') {
      const raw = await request.text();
      const assinatura = request.headers.get('x-hub-signature-256');
      if (!(await valida(raw, assinatura, env.APP_SECRET))) {
        return new Response('Bad signature', { status: 401 });
      }
      ctx.waitUntil(fetch(env.DOWNSTREAM_URL, {
        method: 'POST',
        headers: { 'content-type': 'application/json' },
        body: raw,
      }));
      return new Response('EVENT_RECEIVED', { status: 200 });
    }

    return new Response('Method not allowed', { status: 405 });
  },
};

async function valida(corpo, header, secret) {
  if (!header?.startsWith('sha256=')) return false;
  const key = await crypto.subtle.importKey(
    'raw', new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' }, false, ['sign'],
  );
  const mac = await crypto.subtle.sign('HMAC', key, new TextEncoder().encode(corpo));
  const hex = [...new Uint8Array(mac)].map(b => b.toString(16).padStart(2, '0')).join('');
  const veio = header.slice(7);
  if (hex.length !== veio.length) return false;
  let dif = 0;
  for (let i = 0; i < hex.length; i++) dif |= hex.charCodeAt(i) ^ veio.charCodeAt(i);
  return dif === 0;
}

npm create cloudflare@latest wa-webhook -- --type=hello-world
cd wa-webhook
npx wrangler secret put VERIFY_TOKEN
npx wrangler secret put APP_SECRET
npx wrangler deploy

Session logging

Não é serviço nem log de servidor. É um listener de mensagem na página que abriu o fluxo, e é o único canal por onde chega o aviso de que o onboarding terminou e de que a janela de 24 horas começou a correr.

window.addEventListener('message', (event) => {
  if (!event.origin.endsWith('facebook.com')) return;
  try {
    const data = JSON.parse(event.data);
    if (data.type === 'WA_EMBEDDED_SIGNUP') {
      // guarde session_id, error_code e timestamp.
      // a Meta pede os tres quando voce abre suporte.
    }
  } catch {
    // payload nao-JSON
  }
});

Embedded Signup v4

FB.login(fbLoginCallback, {
  config_id: '<CONFIGURATION_ID>',
  response_type: 'code',
  override_default_response_type: true,
  extras: {
    setup: {},
    featureType: 'whatsapp_business_app_onboarding',  // liga a Coexistence
    sessionInfoVersion: '3',
  },
});

A v2 morre em 15 de outubro de 2026. Construa v4 direto. A migração é mais de configuração que de código: criar uma Configuration nova do Facebook Login for Business, porque a v2 não se reaproveita, e esvaziar o extras, exceto em Coexistence, que é a exceção documentada.

Configuração sem código, e o erro que gera falha silenciosa

• App Meta do tipo Business com use case WhatsApp
• Configuration do Facebook Login for Business, que gera o config_id
• Domínio em Allowed domains e em Valid OAuth redirect URIs. Faltando um dos dois, os IDs e o code não voltam, e a falha é silenciosa
• Seis chaves em Yes: Client OAuth login, Web OAuth login, Enforce HTTPS, Embedded Browser OAuth Login, Strict Mode for redirect URIs, Login with the JavaScript SDK

Troca do code por token

curl --get 'https://graph.facebook.com/v21.0/oauth/access_token' \
  -d 'client_id=<APP_ID>' \
  -d 'client_secret=<APP_SECRET>' \
  -d 'code=<CODE>'

O code tem TTL de 30 segundos. A Meta prevê o modo manual e recomenda montar o comando antes de começar o teste, deixando colado no terminal esperando só o Enter. Sai um Business Integration System User token.

Dia D

A janela de 24 horas começa quando o fluxo termina, e cada sincronização roda uma vez só. Errar exige o cliente fazer offboard pelo celular e refazer tudo.

# 1. assinar webhooks na WABA do cliente
curl -X POST 'https://graph.facebook.com/<VER>/<WABA_ID>/subscribed_apps' \
  -H 'Authorization: Bearer <TOKEN>'

# 2. sincronizar contatos   (UMA VEZ)
curl -X POST 'https://graph.facebook.com/<VER>/<PHONE_ID>/smb_app_data' \
  -H 'Authorization: Bearer <TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{"messaging_product":"whatsapp","sync_type":"smb_app_state_sync"}'

# 3. sincronizar historico  (UMA VEZ)
curl -X POST 'https://graph.facebook.com/<VER>/<PHONE_ID>/smb_app_data' \
  -H 'Authorization: Bearer <TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{"messaging_product":"whatsapp","sync_type":"history"}'

• Guarde o request_id de cada resposta. A Meta pede em suporte
• Em Coexistence, pule o registro do número. Ele já está registrado Oficial
• Webhooks a assinar: account_update, que é obrigatório sempre, mais messages, history, smb_app_state_sync e smb_message_echoes
• Depois disso o cliente cadastra a forma de pagamento no WhatsApp Manager. Sem isso não sai nada

Riscos

Como validar cada etapa

Depois de Tech Provider

Circula um esquema de quatro degraus, ISV → Tech Provider → Tech Partner → Business Partner, com a Meta entrando em contato sozinha quando você bate a meta. Conferimos cada peça na documentação oficial: o desenho está errado, os números existem mas descrevem outra coisa, e o contato automático não existe.

Não é uma escada, são duas trilhas

A página oficial de parceiros lista três tipos, não quatro:

As duas trilhas são paralelas. Não se sobe de Tech Partner para Solution Partner. Oficial

• "Meta ISV" não é um nível. Não aparece na documentação. ISV é termo de mercado para o que a sua empresa é, não o degrau em que ela está Sem fonte
• Meta Business Partner não fica acima de Tech Partner. É o passo 3 dos 5 do próprio upgrade. A definição oficial: "Tech Partners are Tech Providers who are, or are eligible to become, Meta Business Partners" Oficial
• Measurement Partner não é degrau. É papel de leitura para analytics, e o passo 1 do onboarding dele é "Complete Tech Provider onboarding" Oficial
• BSP saiu do vocabulário. A documentação atual usa só Solution Partner. O fóssil do nome antigo é a URL, que segue /solution-providers/. Não achamos comunicado anunciando a troca Sem fonte

A armadilha está na tradução da própria Meta

Ninguém entra em contato: quem inicia é você, em App Dashboard > WhatsApp > Quickstart > Become a Partner > Take the next step. Oficial

Os quatro critérios, e os quatro erros que circulam

O que muda de fato ao subir

O que o Tech Partner ganha, literal: "Training and support · Analytics reports · Client matching opportunities", mais acesso ao Partner Portal e elegibilidade ao MBP SMB Accelerator Program. Oficial

Os cinco passos do upgrade

• 1. App Dashboard > WhatsApp > Quickstart > seção Become a Partner > Take the next step
• 2. Na página Onboarding, rolar até o fim e clicar Become a Partner, o que revela os quatro passos restantes
• 3. Apply now para se candidatar a Meta Business Partner e à WhatsApp Specialty
• 4. Criar conta no Partner Portal: nome, business ID e aceite do acordo
• 5. Aderir ao Business Messaging Accelerate Program e assinar o acordo pelo card no portal

São dois contratos: a candidatura ao MBP e o acordo do Accelerate. Prazo oficial: "a few weeks to complete to get through all of the approvals". Isso conta só as aprovações, não o tempo de chegar aos critérios. Oficial

Onde a Meta se contradiz

O teto de onboarding do Embedded Signup vai de 10 para 200 novos clientes por janela móvel de 7 dias. Passar de 200 por semana é o gatilho documentado para pedir MBP, e não é critério de nível, como às vezes se lê. Oficial

Não existe trilha brasileira

Procuramos e não encontramos programa, critério ou exceção para Brasil ou América Latina. Os critérios são globais. O que o Brasil tem de próprio é produto, não parceria: existe uma seção inteira Payments Brazil na documentação, com Pix, Boleto, payment links e one-click. É diferença relevante para quem vende no Brasil, e não muda a hierarquia de parceiros. Sem fonte

O que ficou sem resposta

Marcado para não virar suposição. Se você tiver a resposta de qualquer um destes com fonte, escreva para a gente e o crédito é seu.

• Limite de caracteres da justificativa de permissão
• Duração, formato ou tamanho máximo do vídeo
• Texto de submissão real e verificável que tenha sido aprovado
• Número típico de rodadas até a aprovação
• Limite oficial de tentativas de reenvio
• Se a Meta segue redirect HTTP em webhook. É por isso que Apps Script está descartado por arquitetura, e não por teste
• Confirmação ou desmentido do relato de que o SDK gera a URL de Embedded Signup em formato errado. As causas documentadas do mesmo sintoma são domínio não cadastrado, override_default_response_type ausente, ou TTL de 30 segundos estourado
• Critérios públicos para virar Solution Partner. A página "Get started as a Solution Partner" é guia técnico e pressupõe que você já foi aprovado. A única pista oficial é a frase "becoming a Solution Partner is a lengthy process"
• Critérios de candidatura ao Meta Business Partners. A página exige login antes de mostrar qualquer coisa
• Como se entra no Partner Showcase, o diretório de parceiros. Que ele existe é oficial; o critério de entrada não é publicado
• Taxa, comissão ou revenue share em qualquer nível. Nada publicado, o que não é o mesmo que ser gratuito: os termos comerciais só aparecem dentro dos acordos, depois do login
• SLA, volume mínimo de manutenção, auditoria periódica, o que faz perder o nível e recurso contra rejeição. Lacuna real da documentação pública, não falha de busca
• Existência de selo visual de Tech Partner. O que existe é a WhatsApp Specialty dentro do MBP, que não é a mesma coisa que o selo do Meta Verified nem que o checkmark de Official Business Account
• Preços diferenciados, acesso antecipado a recursos ou gerente de conta dedicado. Só encontramos isso em blog de fornecedor, sem respaldo oficial
• Relato de primeira mão do upgrade para Tech Partner, com datas reais. Não existe publicamente. A doc de um BSP reproduz os mesmos quatro critérios e a mesma frase "a few weeks": é cópia da doc da Meta, não confirmação independente