Comunidade exclusiva para founders com negócio no WhatsApp em produção. Conecte-se com Tech Providers, Solution Partners e Meta Business Partners. WhatsApp Business API, Cloud API, Embedded Signup e automação no ecossistema Meta Brasil. 2026-07-19T00:00:00+00:00 https://www.whatsappfounders.com.br/artigos/ WhatsApp Founders https://www.whatsappfounders.com.br 2026-07-19T00:00:00+00:00 2026-07-19T00:00:00+00:00 https://www.whatsappfounders.com.br/artigos/erros-api-oficial-whatsapp-o-que-fazer/ Vitor Fontenele

Referência aberta dos erros na API Oficial do WhatsApp — códigos 131xxx no envio, onboarding Embedded Signup, Cloud, Coexistência, WABA e permissões: mensagem Meta, causa e ação prática.

<p>Conectar e operar na <strong>API Oficial do WhatsApp</strong> costuma travar em mensagens genéricas: <em>“número não elegível”</em>, <em>“algo deu errado”</em>, QR que não escaneia, número preso em WABA antiga, sync que nunca termina, permissão negada no Business Manager. A Meta quase nunca explica a causa raiz na tela.</p> <p>Este guia é a referência aberta <strong>erro → causa → ação</strong> para quem implementa Embedded Signup, onboarda clientes ou opera WABA. Erros de <strong>conta, BM, pagamento, permissões e número</strong> valem para <strong>Cloud e Coexistência</strong>; QR, importação e app no celular são só Coexistência.</p> <blockquote> <p><strong>Escopo:</strong> envio (códigos <strong>131xxx</strong> no webhook), onboarding (Embedded Signup) e operação pós-conexão. Templates rejeitados → <a href="/artigos/templates-whatsapp-rejeitados-meta-como-aprovar/">guia de templates</a>. Cloud ou Coexistência → <a href="/artigos/api-oficial-whatsapp-cloud-vs-coexistencia/">comparativo</a>. Selo azul → <a href="/artigos/selo-azul-whatsapp-business-api-oficial-meta/">os três caminhos</a>.</p> </blockquote> <div class="mermaid" data-caption="Diagnóstico rápido: em qual fase da API Oficial o erro apareceu?"> flowchart TD START(["Erro na API Oficial"]) --&gt; MODELO{"Cloud ou Coexistência?"} MODELO --&gt;|Cloud| CLOUD["Embedded Signup → SMS/voz → registro"] MODELO --&gt;|Coexistência| COEX["Embedded Signup → QR → sync"] CLOUD --&gt; FASE{"Em qual etapa?"} COEX --&gt; FASE FASE --&gt;|Antes de conectar| PRE["Pré-requisitos / elegibilidade / WABA anterior"] FASE --&gt;|Embedded Signup| ES["Login, BM, número, permissões, pagamento"] FASE --&gt;|QR / verificação| QR["QR Code ou SMS — conforme o modelo"] FASE --&gt;|Depois de conectar| POS["Sync, dispositivos, automações, operação"] PRE --&gt; ACAO1["Aguardar uso ativo ou limpar WABA antiga"] ES --&gt; ACAO2["Conta, BM, permissão ou pagamento"] QR --&gt; ACAO3["Fluxo correto, app atualizado, refazer signup"] POS --&gt; ACAO4["Wi-Fi, app aberto, desativar conflitos"] </div> <h2 id="pré-requisitos-cloud-e-coexistência">Pré-requisitos (Cloud e Coexistência)</h2> <p>Muitos “erros” são pré-requisito não atendido. Cheque <strong>antes</strong> de abrir ticket:</p> <table> <thead> <tr> <th>Requisito</th> <th>Detalhe</th> </tr> </thead> <tbody> <tr> <td>App (Coexistência)</td> <td><strong>WhatsApp Business</strong> 2.24.17+ (não o pessoal)</td> </tr> <tr> <td>Atividade (Coexistência)</td> <td><strong>7+ dias</strong> no app; ideal <strong>30–60</strong></td> </tr> <tr> <td>BM e Facebook</td> <td>Página + <strong>Meta Business Manager</strong> com <strong>admin</strong></td> </tr> <tr> <td>WABA limpa</td> <td>Número <strong>fora</strong> de outra WABA, BSP ou API não oficial</td> </tr> <tr> <td>Nome da empresa</td> <td>Defina <strong>antes</strong> de conectar (trava depois)</td> </tr> </tbody> </table> <p><strong>Regra de ouro:</strong> número vindo de Z-API, Evolution ou similar → exclua no provedor anterior, use o Business App com conversas reais <strong>1–2 meses</strong>, só então tente a API Oficial de novo. Reconectar no dia seguinte quase sempre falha.</p> <hr /> <h2 id="tabela-mestra-erro--ação">Tabela mestra: erro → ação</h2> <table> <thead> <tr> <th>Mensagem / sintoma</th> <th>Causa provável</th> <th>O que fazer</th> <th>Modelo</th> </tr> </thead> <tbody> <tr> <td><strong>“Mais atividade no WhatsApp Business App é necessária.”</strong></td> <td>Uso insuficiente no app</td> <td>Conversas reais <strong>7–60 dias</strong>. <strong>Não</strong> exclua e re-registre o número.</td> <td>Coex.</td> </tr> <tr> <td><strong>Email: não elegível para Coexistence Onboarding</strong></td> <td>Bloqueio de política</td> <td><strong>Número alternativo</strong>. Revise <a href="https://business.whatsapp.com/policy">política comercial</a>.</td> <td>Coex.</td> </tr> <tr> <td><strong>“Este número está registrado em uma conta WhatsApp existente.”</strong> / <strong>“Esse número já está registrado…“</strong></td> <td>WABA/BSP/API anterior</td> <td>Desconecte no provedor → Business App → <strong>1–2 meses</strong> de uso → tente de novo.</td> <td>Ambos</td> </tr> <tr> <td><strong>“Esse número de telefone já existe na sua lista de números.”</strong></td> <td>Já na WABA atual</td> <td><strong>Selecione o número existente</strong> no fluxo.</td> <td>Ambos</td> </tr> <tr> <td><strong>“O número de telefone foi bloqueado.”</strong></td> <td>Restrição Meta</td> <td>Gerenciador do WhatsApp ou ticket Meta.</td> <td>Ambos</td> </tr> <tr> <td><strong>“Número máximo de telefones vinculados…“</strong></td> <td>Limite na WABA</td> <td>Remova inativos ou use outra WABA/BM.</td> <td>Ambos</td> </tr> <tr> <td><strong>“Nome verificado viola as diretrizes…“</strong></td> <td>Nome fora da política</td> <td>Ajuste conforme <a href="https://developers.facebook.com/docs/whatsapp/display-name">diretrizes de nome</a>.</td> <td>Ambos</td> </tr> <tr> <td><strong>“Verificação do nome já está em andamento.”</strong></td> <td>Nome em análise</td> <td><strong>Aguarde</strong> antes de seguir o signup.</td> <td>Ambos</td> </tr> <tr> <td><strong>QR Code não aparece ou não escaneia</strong></td> <td>App velho, fluxo errado</td> <td>App <strong>2.24.17+</strong>, cache do browser, <strong>Configurações → Conta → Plataforma comercial</strong>.</td> <td>Coex.</td> </tr> <tr> <td><strong>Importação travou</strong> / sync eterno</td> <td>Rede ou volume alto</td> <td>App <strong>aberto</strong>, <strong>Wi-Fi</strong>, até <strong>6 h</strong>. Falhou → reescaneie o QR.</td> <td>Coex.</td> </tr> <tr> <td><strong>Erro ao vincular à Página do Facebook</strong></td> <td>Página ou permissão</td> <td>Admin no BM <strong>e</strong> na Página; dados completos.</td> <td>Ambos</td> </tr> <tr> <td><strong>Windows/WearOS não aparecem na API</strong></td> <td>Dispositivo não suportado</td> <td>Só <strong>WhatsApp Web</strong> e <strong>Mac</strong>.</td> <td>Coex.</td> </tr> <tr> <td><strong>Nome da empresa não altera depois</strong></td> <td>Comportamento pós-coex</td> <td>Ajuste <strong>antes</strong> do QR; depois só suporte Meta.</td> <td>Coex.</td> </tr> <tr> <td><strong>“Limitamos a frequência…“</strong></td> <td>Rate limit</td> <td>Pare tentativas; conta Facebook madura.</td> <td>Ambos</td> </tr> <tr> <td><strong>Sem permissão para anunciar</strong></td> <td>Conta restrita</td> <td>Troque de conta Facebook com admin no BM.</td> <td>Ambos</td> </tr> <tr> <td><strong>Conta Facebook muito nova</strong></td> <td>Conta recente</td> <td><strong>30+ dias</strong> de histórico ou aguarde e retome.</td> <td>Ambos</td> </tr> <tr> <td><strong>Limite de empresas criadas</strong></td> <td>Limite de BMs</td> <td>Use <strong>BM existente</strong>.</td> <td>Ambos</td> </tr> <tr> <td><strong>Conta de pagamento desabilitada</strong></td> <td>Billing pendente</td> <td>Regularize no Suporte Meta.</td> <td>Ambos</td> </tr> <tr> <td><strong>Sem permissão para criar WABA</strong></td> <td>Usuário sem admin</td> <td><strong>Controle total</strong> ou admin WhatsApp no BM.</td> <td>Ambos</td> </tr> <tr> <td><strong>“Algo deu errado. Entre em contato com o suporte.”</strong></td> <td>Erro genérico Meta</td> <td><strong>15–30 min</strong>, cache, retry. Persiste → ticket com print + horário UTC.</td> <td>Ambos</td> </tr> <tr> <td>Escolheu <strong>“Conectar número de telefone”</strong></td> <td>Fluxo PIN / MM Lite</td> <td>Volte e escolha <strong>“Conectar seu aplicativo WhatsApp Business existente”</strong>.</td> <td>Coex.</td> </tr> <tr> <td>Respostas duplicadas</td> <td>App + bot da API</td> <td>Desligue <strong>saudação/ausência</strong> no app antes do chatbot.</td> <td>Coex.</td> </tr> <tr> <td>Conexão caiu semanas depois</td> <td>App <strong>14+ dias</strong> fechado</td> <td>Abra o Business App <strong>a cada 14 dias</strong> (Coexistence Guidelines).</td> <td>Coex.</td> </tr> </tbody> </table> <hr /> <h2 id="coexistência-notas-rápidas">Coexistência: notas rápidas</h2> <p><strong>QR (checklist):</strong> app atualizado → cache do browser → fluxo <strong>Plataforma comercial</strong> → boa iluminação → aguarde 5–15 min → reinstalar app só como último recurso.</p> <p><strong>Sync:</strong> contatos entram sempre; conversas 1:1 até <strong>6 meses</strong> (mídias ~2 semanas); <strong>grupos não</strong> vão para a API. Pulou importação → precisa <strong>desvincular e refazer</strong> o onboarding.</p> <p><strong>Desconectar:</strong> app → <strong>Configurações → Conta → Plataforma de Negócios → Desconectar</strong>. Não desinstale o app para “desconectar”.</p> <hr /> <h2 id="códigos-de-erro-no-envio-131xxx">Códigos de erro no envio (131xxx)</h2> <p>Quando a mensagem não entrega, a Meta devolve <code class="language-plaintext highlighter-rouge">errors[]</code> no webhook de status (<code class="language-plaintext highlighter-rouge">code</code>). Persista o código no seu produto (dashboard, alerta, retry).</p> <table> <thead> <tr> <th>Código</th> <th>O que significa</th> <th>O que fazer</th> </tr> </thead> <tbody> <tr> <td><strong>131042</strong></td> <td>Pagamento</td> <td>Regularize <strong>billing</strong> no BM (cartão, limite, moeda).</td> </tr> <tr> <td><strong>131026</strong></td> <td>Indeliverável</td> <td>Número inválido ou fora do WhatsApp. Confirme E.164.</td> </tr> <tr> <td><strong>131049</strong></td> <td>Saúde do ecossistema</td> <td>Reduza marketing frio; veja <a href="/artigos/quality-rating-evitar-numero-banido-whatsapp/">quality rating</a>.</td> </tr> <tr> <td><strong>131047</strong></td> <td>Janela 24h fechada</td> <td>Só <strong>template aprovado</strong> — veja <a href="/artigos/janela-24-horas-categorias-template-whatsapp/">janela e categorias</a>.</td> </tr> <tr> <td><strong>130472</strong></td> <td>Experimento Meta</td> <td>Destinatário em grupo de teste. Sem workaround.</td> </tr> <tr> <td><strong>131048</strong></td> <td>Spam rate limit</td> <td>Pause campanhas; monitore quality rating.</td> </tr> <tr> <td><strong>131031</strong></td> <td>WABA bloqueada</td> <td>Gerenciador do WhatsApp → ticket Meta com WABA ID.</td> </tr> <tr> <td><strong>131053</strong></td> <td>Mídia</td> <td>Tipo, tamanho ou codec fora do spec.</td> </tr> <tr> <td><strong>131050</strong></td> <td>Opt-out marketing</td> <td>Remova da campanha; só serviço permitido.</td> </tr> <tr> <td><strong>131000</strong></td> <td>Genérico</td> <td>Retry com backoff; ticket com <code class="language-plaintext highlighter-rouge">message_id</code> e horário UTC.</td> </tr> </tbody> </table> <p><strong>Onde aparece:</strong> webhook <code class="language-plaintext highlighter-rouge">messages</code> → <code class="language-plaintext highlighter-rouge">statuses</code> → <code class="language-plaintext highlighter-rouge">errors</code>.</p> <hr /> <h2 id="quando-escalar-para-a-meta">Quando escalar para a Meta</h2> <ul> <li>Número <strong>bloqueado</strong> sem caminho no Gerenciador</li> <li><strong>Inelegibilidade permanente</strong> (email de política) no único canal do cliente</li> <li>Erro genérico <strong>24h+</strong> com pré-requisitos ok</li> <li>Pagamento “desabilitado” sem pendência visível</li> </ul> <p>Leve no ticket: print da mensagem, horário UTC, WABA ID, versão do app, país do número, confirmação de que não há WABA paralela.</p> <hr /> <h2 id="faq">FAQ</h2> <p><strong>Cobre template e envio?</strong> Sim: <strong>131xxx</strong> aqui; reprovação de template no <a href="/artigos/templates-whatsapp-rejeitados-meta-como-aprovar/">guia de templates</a>.</p> <p><strong>WhatsApp pessoal funciona em Coexistência?</strong> Não. Só <strong>Business App</strong>.</p> <p><strong>API não oficial impede?</strong> Sim, enquanto o número estiver registrado lá. Limpe, resfrie, tente depois.</p> <p><strong>Mapa interativo com esses erros?</strong> Membros têm o <a href="/membros/mapa-onboarding-api-oficial/">mapa Meta API</a> com modais por nó. Este artigo é a <strong>versão aberta e pesquisável</strong>.</p> <hr /> <p><em>Referências: <a href="https://developers.facebook.com/docs/whatsapp/cloud-api/">WhatsApp Cloud API</a>, <a href="https://faq.whatsapp.com">Central de Ajuda WhatsApp Business</a>, *WhatsApp Coexistence Guidelines</em>. Regras mudam — valide na documentação oficial antes de prometer prazo ao cliente.*</p> <p><em>Conteúdo da comunidade WhatsApp Founders 🇧🇷 — independente, sem vínculo oficial com o WhatsApp ou a Meta.</em></p> 2026-06-28T00:00:00+00:00 2026-06-28T00:00:00+00:00 https://www.whatsappfounders.com.br/artigos/selo-azul-whatsapp-business-api-oficial-meta/ Vitor Fontenele

O 'selo azul' não é um produto só. App tem Meta Verified por assinatura; API Oficial tem verificação por aprovação da Meta; Coexistência não tem selo. Guia para quem onboarda clientes na WhatsApp Business API.

<p>“Vocês conseguem o selo azul pra mim?” é provavelmente a pergunta que mais chega para quem trabalha com a WhatsApp Business API no Brasil. E a resposta honesta é: <strong>depende de qual selo, em qual produto, e como o número está conectado.</strong></p> <p>O problema é que “selo azul” virou um nome guarda-chuva para três coisas tecnicamente diferentes. Quem onboarda cliente sem separar essas três acaba prometendo o que a Meta não vai entregar — e a conta sobra para o parceiro. Este guia separa os três caminhos para você orientar com precisão.</p> <div class="mermaid" data-caption="Três caminhos do selo azul: assinatura no app, aprovação na API Oficial, inexistente na Coexistência."> flowchart LR subgraph app["WhatsApp Business app"] A(["Meta Verified<br />assinatura paga"]) end subgraph cloud["API Oficial Cloud"] B(["Aprovação da Meta<br />sem assinatura"]) end subgraph coex["Coexistência"] C(["Sem selo"]) end </div> <figure class="post__figure"> <img src="/assets/images/linkedin-posts/linkedin-post-09.png" alt="Tipos de parceria da Meta no ecossistema WhatsApp Business API" width="1200" height="630" loading="lazy" decoding="async" /> <figcaption>O selo do app não migra para a API — são produtos e filas de análise diferentes.</figcaption> </figure> <h2 id="o-selo-azul-não-é-um-produto-só">O “selo azul” não é um produto só</h2> <p>O badge azul de verificação aparece em mais de um lugar do ecossistema Meta, e ele é concedido por mecanismos distintos dependendo de onde o número vive:</p> <h3 id="1-whatsapp-business-app--selo-por-assinatura-meta-verified">1. WhatsApp Business (app) — selo por <strong>assinatura</strong> (Meta Verified)</h3> <p>No aplicativo WhatsApp Business, o selo vem do <strong>Meta Verified</strong>, a assinatura paga da Meta (a mesma linha que verifica perfis de Instagram e Facebook). É um produto comercial: o cliente assina, passa pela validação e recebe o badge.</p> <ul> <li><strong>Como obtém:</strong> assinatura mensal recorrente.</li> <li><strong>Custo:</strong> pago (na faixa de ~R$ 55/mês para o WhatsApp no Brasil — confira o valor atual no app, varia por mercado e plano).</li> <li><strong>Requisitos:</strong> perfil completo, conta no Meta Business Manager com 2FA, nome de exibição compatível com a empresa, boa nota de qualidade e conformidade com as políticas.</li> <li><strong>Dificuldade:</strong> acessível. É o caminho mais previsível para o cliente que opera só no app.</li> </ul> <h3 id="2-api-oficial-cloud--selo-por-aprovação-da-meta">2. API Oficial (Cloud) — selo por <strong>aprovação</strong> da Meta</h3> <p>Na API Oficial conectada via Cloud, o selo <strong>não é o Meta Verified</strong> e <strong>não é uma assinatura</strong>. Ele é concedido por <strong>análise e aprovação da Meta</strong>, com critérios mais rígidos — notoriedade de marca, histórico de qualidade e verificação de negócio completa.</p> <ul> <li><strong>Como obtém:</strong> solicitação dentro do WhatsApp Manager → análise da Meta.</li> <li><strong>Custo:</strong> sem assinatura específica (faz parte da operação na API).</li> <li><strong>Requisitos:</strong> verificação de negócio concluída, marca com presença/notoriedade comprovável, boa qualidade do número.</li> <li><strong>Dificuldade:</strong> restritiva. Aprovação não é garantida e o prazo de análise costuma ser de alguns dias úteis.</li> </ul> <blockquote> <p><strong>Ponto que confunde todo mundo:</strong> ter API Oficial <strong>não dá</strong> selo automaticamente, e o selo do app (Meta Verified) <strong>não migra</strong> para a API. São produtos diferentes, com filas de análise diferentes.</p> </blockquote> <h3 id="3-coexistência--não-tem-selo">3. Coexistência — <strong>não tem selo</strong></h3> <p>Na conexão por Coexistência (o número roda no app <strong>e</strong> na API ao mesmo tempo), <strong>não existe caminho para o selo azul</strong>. É uma limitação do próprio modelo. Se o selo é inegociável para o cliente, Coexistência está fora — e isso precisa ser dito no início do projeto, não depois.</p> <h2 id="comparativo-dos-três-caminhos">Comparativo dos três caminhos</h2> <table> <thead> <tr> <th>Aspecto</th> <th>WhatsApp Business (app)</th> <th>API Oficial (Cloud)</th> <th>Coexistência</th> </tr> </thead> <tbody> <tr> <td>Como obtém o selo</td> <td>Assinatura (Meta Verified)</td> <td>Aprovação da Meta</td> <td>Não disponível</td> </tr> <tr> <td>Custo</td> <td>Pago (~R$ 55/mês)</td> <td>Sem assinatura própria</td> <td>—</td> </tr> <tr> <td>Requisito principal</td> <td>Perfil + documentação</td> <td>Verificação de negócio + notoriedade</td> <td>—</td> </tr> <tr> <td>Dificuldade</td> <td>Acessível</td> <td>Restritiva</td> <td>Sem caminho</td> </tr> <tr> <td>Garantia</td> <td>Alta (se cumprir critérios)</td> <td>Baixa (análise da Meta)</td> <td>Nenhuma</td> </tr> </tbody> </table> <h2 id="o-que-muda-na-migração-a-parte-que-dói">O que muda na migração (a parte que dói)</h2> <p>Aqui está o detalhe que mais gera atrito no onboarding: <strong>migrar para a API Oficial via Cloud encerra a conexão do app — e o selo Meta Verified do app não vai junto.</strong> O número passa a depender de uma nova solicitação de verificação, agora pelo caminho de aprovação da API, que é mais rígido e pode ser negado.</p> <p>Tradução para o discurso com o cliente: se ele tem o selo no app hoje e vai para Cloud, ele <strong>perde o selo na migração</strong> e precisa reconquistá-lo por outro processo. Se isso não for alinhado antes, vira reclamação na sua porta.</p> <p>Na Coexistência o selo também não é garantido (e, como vimos, não há caminho ativo para ele). Ou seja: <strong>não prometa selo em projeto de Coexistência.</strong></p> <h2 id="requisitos-e-como-solicitar">Requisitos e como solicitar</h2> <p><strong>Pelo app (Meta Verified):</strong></p> <ol> <li>Conta no <strong>Meta Business Manager</strong> verificada e com 2FA ativo.</li> <li><strong>Nome de exibição</strong> igual ao nome registrado da empresa.</li> <li>Boa <strong>nota de qualidade</strong> da conta WhatsApp Business.</li> <li>Conformidade com os Termos e a Política Comercial do WhatsApp.</li> <li>No app: <strong>Configurações → Meta Verified → escolher plano → enviar documentos</strong> (ex.: CNPJ, comprovante). Aprovação costuma sair em 24–48h.</li> </ol> <p><strong>Pela API Oficial (aprovação):</strong></p> <ol> <li><strong>Verificação de negócio</strong> concluída no Business Manager.</li> <li>Acesse <strong>WhatsApp Manager → número → Configurações → Perfil</strong> e solicite o selo.</li> <li>A análise da Meta leva, em geral, alguns dias úteis (na faixa de 5 a 7).</li> </ol> <p><strong>Se for negado:</strong> não adianta reenviar no dia seguinte. Espere a janela indicada (costuma ser ~30 dias), fortaleça a presença e a notoriedade da marca (site, imprensa, presença orgânica) e tente de novo. Para o caminho de aprovação, <strong>notoriedade de marca pesa mais do que qualquer truque de formulário.</strong></p> <h2 id="como-orientar-seu-cliente-playbook-do-parceiro">Como orientar seu cliente (playbook do parceiro)</h2> <ul> <li><strong>Descubra o produto antes de prometer.</strong> App, Cloud ou Coexistência? A resposta define se o selo é “assinatura”, “aprovação” ou “não existe”.</li> <li><strong>Separe selo de credibilidade.</strong> O <strong>nome verificado da empresa</strong> (display name aprovado) já aparece para o destinatário sem ele salvar o contato — isso entrega boa parte da percepção de confiança, independentemente do badge azul.</li> <li><strong>Alinhe a perda na migração por escrito.</strong> Cliente com selo no app indo para Cloud precisa saber que vai perdê-lo temporariamente.</li> <li><strong>Não venda selo em Coexistência.</strong> Posicione os ganhos reais do modelo (histórico preservado, transição suave) sem prometer badge.</li> </ul> <h2 id="perguntas-frequentes">Perguntas frequentes</h2> <p><strong>Ter API Oficial garante o selo azul?</strong> Não. Na API o selo é por aprovação da Meta, com critérios rígidos e sem garantia. API e selo são coisas separadas.</p> <p><strong>O selo do app vale na API?</strong> Não. O Meta Verified do app não migra para a API. São produtos e filas de análise diferentes.</p> <p><strong>Coexistência tem selo?</strong> Não. O modelo de Coexistência não oferece caminho para o badge azul.</p> <p><strong>O cliente perde o selo ao migrar para Cloud?</strong> Sim, o selo do app não acompanha a migração para Cloud. Ele precisará solicitar a verificação novamente pelo caminho da API.</p> <hr /> <p><em>Padrões de produto, preços e critérios da Meta mudam com frequência. Confirme sempre na fonte oficial: <a href="https://faq.whatsapp.com">Central de Ajuda do WhatsApp</a> e <a href="https://www.facebook.com/business/help">Meta Business Help Center</a>.</em></p> <p><em>Conteúdo da comunidade WhatsApp Founders 🇧🇷 — independente, sem vínculo oficial com o WhatsApp ou a Meta.</em></p> 2026-06-28T00:00:00+00:00 2026-06-28T00:00:00+00:00 https://www.whatsappfounders.com.br/artigos/api-oficial-whatsapp-cloud-vs-coexistencia/ Vitor Fontenele

Cloud ou Coexistência na WhatsApp Business API? Comparativo direto para founders e builders: histórico, selo, respostas duplicadas, pré-requisitos e quando escolher cada modelo de conexão.

<p>Toda vez que um founder ou builder coloca um número na <strong>WhatsApp Business API</strong>, a primeira decisão de arquitetura é a mesma: <strong>Cloud ou Coexistência?</strong> Escolher errado aqui significa, em alguns casos, perder o histórico de conversas do cliente ou descobrir tarde demais que o número precisava continuar funcionando no celular.</p> <p>Este é o comparativo direto, sem rodeio, para quem vai operar — não para quem vai só assistir.</p> <div class="mermaid" data-caption="Árvore de decisão: histórico e celular no dia a dia apontam para Coexistência; número novo e centralização apontam para Cloud."> flowchart TD START{"Precisa do histórico<br />e do app no celular?"} START --&gt;|Sim| COEX["Coexistência<br />importa até 6 meses"] START --&gt;|Não| CLOUD["Cloud<br />tudo na nuvem"] COEX --&gt; WARN["Desligar respostas<br />automáticas do app"] CLOUD --&gt; NOTE["Histórico zerado<br />selo do app perdido"] </div> <h2 id="a-api-oficial-em-30-segundos">A API Oficial em 30 segundos</h2> <p>A API Oficial é o canal que a Meta oferece para empresas atenderem em escala no WhatsApp: múltiplos atendentes no mesmo número, automação, chatbots, integração com CRM e disparo de templates. A conexão desse número à API acontece por um de dois modelos: <strong>Cloud</strong> ou <strong>Coexistência</strong>.</p> <h2 id="cloud-tudo-na-nuvem">Cloud: tudo na nuvem</h2> <h3 id="como-funciona">Como funciona</h3> <p>O número é migrado <strong>inteiramente para a nuvem da Meta</strong>. O WhatsApp Business no celular é <strong>desconectado</strong> — daquele momento em diante, todo envio e recebimento passa exclusivamente pela API/plataforma.</p> <h3 id="prós">Prós</h3> <ul> <li><strong>Estabilidade máxima:</strong> não depende de celular ligado nem de app aberto.</li> <li><strong>Sem interferência:</strong> chatbots e automações operam sem o app respondendo por fora.</li> <li><strong>Operação centralizada:</strong> tudo num só lugar, do jeito que escala bem.</li> </ul> <h3 id="contras">Contras</h3> <ul> <li><strong>O histórico NÃO é transferido.</strong> A operação começa do zero.</li> <li><strong>O selo do app (Meta Verified) é perdido</strong> na migração (veja o porquê em <a href="/artigos/selo-azul-whatsapp-business-api-oficial-meta/">Selo azul no WhatsApp Business</a>).</li> <li>O celular <strong>perde</strong> o WhatsApp daquele número.</li> </ul> <h2 id="coexistência-app-e-api-no-mesmo-número">Coexistência: app e API no mesmo número</h2> <h3 id="como-funciona-1">Como funciona</h3> <p>O número <strong>continua ativo no app</strong> WhatsApp Business no celular <strong>e</strong>, ao mesmo tempo, na API via plataforma. As mensagens sincronizam entre os dois.</p> <h3 id="o-que-acontece-com-o-histórico">O que acontece com o histórico</h3> <p>Esse é o grande diferencial: a Coexistência <strong>importa o histórico</strong> — até <strong>6 meses de conversas 1:1</strong> (mídias dos últimos ~15 dias). Os contatos sincronizam automaticamente. Conversas de <strong>grupo não</strong> são importadas.</p> <h3 id="prós-1">Prós</h3> <ul> <li><strong>Preserva o histórico e os contatos</strong> — transição suave, sem perder contexto.</li> <li>O time pode <strong>continuar usando o app no celular</strong> durante a adoção gradual.</li> <li>Menos ruptura operacional no go-live.</li> </ul> <h3 id="contras-1">Contras</h3> <ul> <li><strong>Selo não é garantido</strong> (e não há caminho ativo para o badge em Coexistência).</li> <li><strong>Depende do app:</strong> é preciso abrir o WhatsApp no celular ao menos uma vez a cada ~14 dias para manter a conexão.</li> <li><strong>Risco de resposta duplicada</strong> se o app e o chatbot responderem juntos (detalhe crítico — abaixo).</li> <li>Compatível com WhatsApp <strong>Web e Mac</strong>; <strong>não</strong> com Windows nem WearOS.</li> </ul> <h2 id="comparativo-direto">Comparativo direto</h2> <table> <thead> <tr> <th>Aspecto</th> <th>Cloud</th> <th>Coexistência</th> </tr> </thead> <tbody> <tr> <td>Histórico de conversas</td> <td>Não transfere (começa do zero)</td> <td>Importa (até 6 meses, 1:1)</td> </tr> <tr> <td>WhatsApp no celular</td> <td>Desconectado</td> <td>Continua ativo</td> </tr> <tr> <td>Sincronização de contatos</td> <td>Não</td> <td>Automática</td> </tr> <tr> <td>Selo (Meta Verified)</td> <td>Perde na migração</td> <td>Não garantido</td> </tr> <tr> <td>Estabilidade</td> <td>Alta (independe do celular)</td> <td>Depende do app aberto</td> </tr> <tr> <td>Mensagem duplicada</td> <td>Não</td> <td>Possível (se ambos responderem)</td> </tr> <tr> <td>Quando faz sentido</td> <td>Número novo / histórico não importa</td> <td>Histórico tem valor / time usa o celular</td> </tr> </tbody> </table> <figure class="post__figure"> <img src="/assets/images/linkedin-posts/linkedin-post-06.png" alt="Comparativo entre Cloud API e BSP na conexão da WhatsApp Business API" width="1200" height="630" loading="lazy" decoding="async" /> <figcaption>Muitas operações começam em Coexistência e migram para Cloud quando a automação amadurece.</figcaption> </figure> <h2 id="o-detalhe-que-pega-todo-builder-respostas-duplicadas">O detalhe que pega todo builder: respostas duplicadas</h2> <p>Em Coexistência, a mensagem que chega aparece <strong>no app e na plataforma</strong>. Se o cliente deixou ligadas as <strong>respostas automáticas do WhatsApp Business</strong> (mensagem de saudação, mensagem de ausência) e você sobe um chatbot na API, os dois respondem — e o usuário recebe a resposta <strong>duas vezes</strong>.</p> <p>A regra prática ao implementar Coexistência com automação:</p> <blockquote> <p>Desligue as respostas automáticas do app (saudação e ausência) antes de ativar o chatbot. Uma conversa, um respondente.</p> </blockquote> <p>Isso parece óbvio depois que você sabe, mas é o ticket de suporte número um de quem subiu Coexistência sem checar.</p> <h2 id="selo-e-histórico-na-migração">Selo e histórico na migração</h2> <p>Resumo do que muda quando o número entra na API:</p> <ul> <li><strong>Cloud:</strong> perde o histórico <strong>e</strong> o selo do app. Ganha estabilidade.</li> <li><strong>Coexistência:</strong> mantém o histórico, mas <strong>não garante selo</strong>.</li> </ul> <p>Se o selo é requisito do cliente, isso muda a conversa inteira — trate o assunto no <a href="/artigos/selo-azul-whatsapp-business-api-oficial-meta/">guia do selo azul</a> antes de fechar a arquitetura.</p> <h2 id="pré-requisitos-da-coexistência">Pré-requisitos da Coexistência</h2> <ul> <li>WhatsApp Business <strong>app v2.24.17+</strong>.</li> <li>Número ativo no app há <strong>pelo menos 7 dias</strong> (recomendável 30–60 para estabilidade).</li> <li><strong>Página do Facebook</strong> da empresa com acesso de administrador + Meta Business Manager.</li> <li>Número <strong>não</strong> pode estar conectado a APIs de terceiros não oficiais (Z-API, Evolution e similares).</li> <li>Suportado no Brasil.</li> </ul> <h2 id="e-os-custos">E os custos?</h2> <p>O modelo de cobrança da API é da Meta, não do tipo de conexão — Cloud e Coexistência seguem a <strong>mesma tabela</strong>. Em linhas gerais: respostas dentro da <strong>janela de atendimento de 24h</strong> e mensagens iniciadas pelo usuário têm tratamento diferente de <strong>templates</strong> (utilidade, marketing, autenticação) enviados fora da janela.</p> <p>A Meta revisa essa política com frequência (a precificação por conversa deu lugar à cobrança por mensagem, com regras específicas por categoria). A partir de <strong>1º de outubro de 2026</strong>, inclusive as mensagens de <strong>serviço</strong> e de <strong>utilidade na janela de 24h</strong> — hoje gratuitas — passam a ser cobradas por mensagem. <strong>Não decore números: confira sempre a <a href="https://developers.facebook.com/docs/whatsapp/pricing/">tabela oficial de preços da Meta</a> vigente</strong> antes de orçar para o cliente.</p> <h2 id="qual-recomendar">Qual recomendar</h2> <p><strong>Escolha Cloud se:</strong></p> <ul> <li>o histórico não é crítico (número novo, ou começo de operação);</li> <li>ninguém precisa mais do número no celular;</li> <li>centralização e estabilidade são prioridade.</li> </ul> <p><strong>Escolha Coexistência se:</strong></p> <ul> <li>o histórico tem valor (o número já é o canal do negócio);</li> <li>o time ainda atende pelo celular e a adoção será gradual;</li> <li>você quer transição suave antes de centralizar de vez.</li> </ul> <p><strong>Na prática:</strong> muita operação pequena e média começa melhor em <strong>Coexistência</strong> (transição sem trauma) e migra para <strong>Cloud</strong> depois, quando a automação já está madura. O caminho <strong>Coexistência → Cloud</strong> é simples; o inverso, bem mais trabalhoso. Decida pensando em onde o cliente vai querer estar daqui a um ano.</p> <h2 id="perguntas-frequentes">Perguntas frequentes</h2> <p><strong>Dá para sair de Coexistência para Cloud depois?</strong> Sim, e é tranquilo — o número já está na Cloud API; basta desativar o app. O caminho inverso (Cloud → Coexistência) é bem mais complicado.</p> <p><strong>Chatbot funciona em Coexistência?</strong> Funciona, desde que você desligue as respostas automáticas do app para não duplicar resposta.</p> <p><strong>WhatsApp Web funciona com Coexistência?</strong> Sim (Web e Mac como dispositivos vinculados). Windows e WearOS não.</p> <p><strong>O histórico de grupos é importado na Coexistência?</strong> Não. Só conversas 1:1. Grupos permanecem apenas no app.</p> <p><strong>Preciso manter o celular ligado em Coexistência?</strong> Para a sincronização inicial, sim. Depois, abra o app pelo menos uma vez a cada ~14 dias para manter a conexão viva.</p> <hr /> <p><em>Referências e regras (selo, histórico, pré-requisitos, precificação) seguem a documentação oficial da Meta/WhatsApp e mudam com frequência — valide na fonte: <a href="https://developers.facebook.com/docs/whatsapp/cloud-api/">WhatsApp Cloud API</a> e <a href="https://faq.whatsapp.com">Central de Ajuda do WhatsApp</a>.</em></p> <p><em>Conteúdo da comunidade WhatsApp Founders 🇧🇷 — independente, sem vínculo oficial com o WhatsApp ou a Meta.</em></p> 2026-06-27T00:00:00+00:00 2026-06-27T00:00:00+00:00 https://www.whatsappfounders.com.br/artigos/templates-whatsapp-rejeitados-meta-como-aprovar/ Vitor Fontenele

Os motivos reais por que a Meta rejeita templates do WhatsApp — category mismatch, placeholder solto, formatação spam — e o checklist de QA para aprovar de primeira.

<p>Você submete um template, espera, e volta <code class="language-plaintext highlighter-rouge">REJECTED</code>. Sem explicação detalhada, sem linha de log útil — só o status e, se tiver sorte, um <code class="language-plaintext highlighter-rouge">reason</code> genérico no webhook. Para quem está construindo na WhatsApp Business API, isso trava onboarding, atrasa campanha e queima tempo de engenharia em algo que deveria ser trivial.</p> <p>A boa notícia: rejeição quase nunca é azar. A Meta revisa cada template (geralmente em minutos, às vezes mais) e a maioria das reprovações cai em três ou quatro padrões previsíveis. Se você entende o que o revisor — humano ou modelo — está procurando, dá para aprovar de primeira de forma consistente. Este guia mapeia os motivos reais e fecha com um checklist de QA antes de submeter.</p> <h2 id="o-que-acontece-na-revisão">O que acontece na revisão</h2> <p>Todo template passa por um estado: <code class="language-plaintext highlighter-rouge">PENDING</code> → <code class="language-plaintext highlighter-rouge">APPROVED</code> ou <code class="language-plaintext highlighter-rouge">REJECTED</code>. A revisão combina checagem automática e, em alguns casos, revisão humana. O resultado chega no webhook <code class="language-plaintext highlighter-rouge">message_template_status_update</code>, com um campo <code class="language-plaintext highlighter-rouge">reason</code> quando reprova.</p> <p>O ponto que pega quase todo mundo: a revisão não olha só “tem palavrão?”. Ela avalia <strong>se a categoria declarada bate com o conteúdo</strong>, <strong>se os placeholders fazem sentido</strong>, e <strong>se a mensagem parece confiável para quem recebe</strong>. É um filtro de qualidade e de política ao mesmo tempo.</p> <div class="mermaid" data-caption="Fluxo de aprovação de template: da criação ao envio em produção ou correção após rejeição."> flowchart LR A["Criar template"] --&gt; B["POST API"] B --&gt; C{"Revisão Meta"} C --&gt;|OK| D(["Enviar msgs"]) C --&gt;|Rejeitado| E["Erro + motivo"] E --&gt; F["Corrigir"] F --&gt; B </div> <h2 id="os-motivos-que-mais-reprovam">Os motivos que mais reprovam</h2> <h3 id="1-category-mismatch">1. Category mismatch</h3> <p>O erro número um. Você escreve uma promoção (“20% OFF essa semana!”) e submete como <code class="language-plaintext highlighter-rouge">UTILITY</code> porque utilidade é mais barata. A Meta detecta o conteúdo de marketing e <strong>rejeita ou recategoriza</strong> — e se recategorizar, você paga preço de marketing achando que pagava utilidade.</p> <p>Regra prática: <code class="language-plaintext highlighter-rouge">MARKETING</code> para promoção e reengajamento; <code class="language-plaintext highlighter-rouge">UTILITY</code> para transacional (confirmação de pedido, atualização de status, lembrete de cobrança); <code class="language-plaintext highlighter-rouge">AUTHENTICATION</code> só para OTP. Se a mensagem existe por causa de uma ação que o usuário tomou (comprou, agendou, pediu código), é utility. Se existe porque <em>você</em> quer vender algo, é marketing. (A diferença de categoria também muda o que você pode enviar dentro da <a href="/artigos/janela-24-horas-categorias-template-whatsapp/">janela de 24 horas</a>.)</p> <h3 id="2-variáveis-e-placeholders">2. Variáveis e placeholders</h3> <p><code class="language-plaintext highlighter-rouge">1</code> sem sample, variável solta no começo ou no fim do body, duas variáveis adjacentes (<code class="language-plaintext highlighter-rouge">1 2</code> sem texto entre elas), ou número de samples diferente do número de variáveis — tudo isso reprova por formato.</p> <p>O revisor precisa entender o que cada placeholder representa. Um body que começa com <code class="language-plaintext highlighter-rouge">1, ...</code> sem contexto antes parece genérico demais. Sempre coloque texto fixo antes da primeira variável e <strong>preencha valores de exemplo realistas</strong> ao submeter.</p> <h3 id="3-formatação-que-parece-spam">3. Formatação que parece spam</h3> <p>Excesso de emoji, CAIXA ALTA, <code class="language-plaintext highlighter-rouge">URLs</code> quebradas ou com placeholder no domínio, caracteres especiais demais, erros de gramática. Tudo isso baixa o “sinal de confiança” da mensagem. <code class="language-plaintext highlighter-rouge">CLIQUE AQUI!!!</code> é praticamente um gatilho de rejeição.</p> <h3 id="4-violação-de-política">4. Violação de política</h3> <p>Conteúdo proibido, enganoso, urgência falsa (“ÚLTIMA CHANCE — sua conta será bloqueada”), pedido de dados sensíveis por link, ou uso indevido de marca de terceiros / imitação de mensagens do próprio WhatsApp/Meta. Isso cai como <code class="language-plaintext highlighter-rouge">SCAM</code> ou <code class="language-plaintext highlighter-rouge">ABUSIVE_CONTENT</code>.</p> <h3 id="5-conteúdo-vago-demais">5. Conteúdo vago demais</h3> <p><code class="language-plaintext highlighter-rouge">Clique aqui</code>, frases incompletas, mensagem sem deixar claro quem manda e por quê. Se o destinatário não entende o contexto, o revisor também não.</p> <h2 id="tabela-motivo-da-rejeição--como-corrigir">Tabela: motivo da rejeição → como corrigir</h2> <table> <thead> <tr> <th>Motivo da rejeição</th> <th>Como corrigir</th> </tr> </thead> <tbody> <tr> <td><strong>Category mismatch</strong> (marketing como utility/auth)</td> <td>Recategorize pelo objetivo real: promoção → marketing; transacional → utility; OTP → authentication.</td> </tr> <tr> <td><strong>Placeholder ambíguo / sem sample</strong></td> <td>Dê nome/contexto a cada ``, nunca comece ou termine o body com variável, e preencha samples realistas.</td> </tr> <tr> <td><strong>Variáveis adjacentes ou contagem errada</strong></td> <td>Separe variáveis com texto fixo; garanta um sample por variável.</td> </tr> <tr> <td><strong>Formatação spam</strong> (CAIXA ALTA, emoji em excesso, “CLIQUE AQUI!!!”)</td> <td>Tom neutro, pontuação normal, no máximo 1–2 emojis, gramática revisada.</td> </tr> <tr> <td><strong>URL inválida / placeholder no domínio</strong></td> <td>Use uma URL real e acessível; nada de <code class="language-plaintext highlighter-rouge">https://seudominio.com</code>.</td> </tr> <tr> <td><strong>Violação de política</strong> (golpe, urgência falsa, marca de terceiros)</td> <td>Remova urgência artificial e pedido de dados sensíveis; não imite mensagens da Meta/WhatsApp.</td> </tr> <tr> <td><strong>Conteúdo vago</strong> (“clique aqui”, frase incompleta)</td> <td>Deixe explícito quem envia, por quê, e o que a pessoa deve fazer.</td> </tr> <tr> <td><strong>Nome do template inválido</strong></td> <td>Apenas minúsculas, números e underscore (ex.: <code class="language-plaintext highlighter-rouge">pedido_confirmado_v2</code>).</td> </tr> </tbody> </table> <div class="mermaid" data-caption="Escolha da categoria conforme o objetivo: transacional → Utility, promoção → Marketing, OTP → Authentication."> flowchart TD Q{"Qual o objetivo?"} Q --&gt;|"Atualizar pedido, status, cobrança"| UTL["Utility"] Q --&gt;|"Promoção, oferta, reengajamento"| MKT["Marketing"] Q --&gt;|"Código de verificação"| AUTH["Authentication"] </div> <h2 id="antes-e-depois-de-um-template">Antes e depois de um template</h2> <p>Veja um template que <strong>será rejeitado</strong> — marketing disfarçado de utility, placeholder solto e formatação de spam:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Categoria: UTILITY Header: 🔥🔥 OFERTA IMPERDÍVEL 🔥🔥 Body: 1 CLIQUE AQUI AGORA!!! Só hoje você ganha desconto. Acesse https://seusite.com/promo </code></pre></div></div> <p>Problemas: é promoção marcada como utility (category mismatch), o body começa com <code class="language-plaintext highlighter-rouge">1</code> sem contexto, tem CAIXA ALTA, emoji em excesso, URL com domínio-placeholder e zero opt-in.</p> <p>Agora a versão corrigida, como <strong>utility legítima</strong> (uma confirmação real), com samples preenchidos:</p> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Categoria: UTILITY Header: Pedido confirmado Body: Olá 1, seu pedido 2 foi confirmado e já está em separação. Você pode acompanhar o status pelo botão abaixo. Sample: 1 = "Ana", 2 = "#10482" Botão: URL → "Acompanhar pedido" </code></pre></div></div> <p>Texto antes da variável, contexto claro, categoria honesta, URL válida no botão. Esse passa.</p> <blockquote> <p>Se você lê a mensagem como destinatário e fica claro <strong>quem manda, por que manda e o que fazer</strong> — sem CAIXA ALTA nem urgência fabricada — o template quase sempre aprova. A categoria certa é metade da batalha.</p> </blockquote> <h2 id="templates-aprovados-também-podem-ser-pausados">Templates aprovados também podem ser pausados</h2> <p>Aprovar não é “para sempre”. Um template aprovado, mas de baixa qualidade na prática, pode ser <strong>pausado ou desabilitado</strong> se os usuários reagirem mal — bloqueios, denúncias de spam, baixa leitura. O status vira <code class="language-plaintext highlighter-rouge">PAUSED</code> e o template para de enviar até a qualidade melhorar.</p> <p>Isso conecta direto ao quality rating do seu número: template ruim derruba o rating, rating ruim pausa templates e estreita seu limite de envio. Monitorar o webhook de status e medir engajamento por template não é luxo — é o que evita descobrir o problema tarde demais.</p> <h2 id="checklist-de-qa-antes-de-submeter">Checklist de QA antes de submeter</h2> <p>Antes de mandar qualquer template para revisão:</p> <ul> <li><strong>Categoria honesta</strong> — promoção é marketing, ponto. Não tente economizar disfarçando.</li> <li><strong>Samples preenchidos</strong> com valores realistas, um por variável.</li> <li><strong>Sem variável no começo/fim</strong> do body e sem variáveis adjacentes.</li> <li><strong>URLs reais</strong> e acessíveis (nada de <code class="language-plaintext highlighter-rouge">seudominio.com</code>).</li> <li><strong>Tom neutro</strong> — sem CAIXA ALTA, sem <code class="language-plaintext highlighter-rouge">!!!</code>, no máximo 1–2 emojis.</li> <li><strong>Gramática revisada</strong> — erro de português baixa o sinal de confiança.</li> <li><strong>Nome válido</strong> — minúsculas, números, underscore.</li> <li><strong>Opt-in coerente</strong> — se é marketing, a pessoa optou por receber? Inclua opção de sair.</li> <li><strong>Reuse padrões aprovados</strong> — se um template já passou, parta dele em vez de inventar do zero.</li> </ul> <p>Esse último ponto vale ouro para quem opera em escala: padronize um punhado de templates por categoria que você sabe que passam, e versione (<code class="language-plaintext highlighter-rouge">_v2</code>, <code class="language-plaintext highlighter-rouge">_v3</code>) em vez de recriar.</p> <h2 id="perguntas-frequentes">Perguntas frequentes</h2> <p><strong>Quanto tempo leva a revisão de um template?</strong> Em geral minutos, mas pode levar mais quando entra revisão humana. Não há SLA garantido — planeje submeter com antecedência, não na véspera da campanha.</p> <p><strong>A Meta diz exatamente por que rejeitou?</strong> Nem sempre. Você recebe um <code class="language-plaintext highlighter-rouge">reason</code> no webhook (<code class="language-plaintext highlighter-rouge">INCORRECT_CATEGORY</code>, <code class="language-plaintext highlighter-rouge">INVALID_FORMAT</code>, <code class="language-plaintext highlighter-rouge">SCAM</code>, <code class="language-plaintext highlighter-rouge">ABUSIVE_CONTENT</code> ou <code class="language-plaintext highlighter-rouge">NONE</code>), mas o detalhamento costuma ser raso. Quando vier <code class="language-plaintext highlighter-rouge">NONE</code>, revise o template inteiro: contexto, tom, variáveis e opt-in.</p> <p><strong>Posso editar um template já aprovado em vez de criar outro?</strong> Sim, a Meta permite editar templates aprovados; a edição vai para nova revisão e, enquanto isso, a versão anterior continua valendo. Verifique as regras atuais de edição na documentação oficial, porque mudam.</p> <p><strong>Por que o de Authentication aprova quase sempre?</strong> Porque segue um formato padrão da Meta (OTP). Quanto menos você customiza, mais rápido passa. Não tente “enfeitar” um template de código de verificação.</p> <hr /> <p><em>As diretrizes de template e os motivos de rejeição mudam com frequência — valide sempre na fonte oficial: <a href="https://developers.facebook.com/docs/whatsapp/business-management-api/message-templates">diretrizes de message templates da Meta</a> e nas políticas vigentes.</em> <em>Conteúdo da comunidade WhatsApp Founders 🇧🇷 — independente, sem vínculo oficial com o WhatsApp ou a Meta.</em></p> 2026-06-25T00:00:00+00:00 2026-06-25T00:00:00+00:00 https://www.whatsappfounders.com.br/artigos/quality-rating-evitar-numero-banido-whatsapp/ Vitor Fontenele

Quality rating, tiers de envio e status do número na WhatsApp Business API. O playbook prático para founders e builders protegerem o ativo mais frágil do projeto: o número.

<p>Para quem constrói na WhatsApp Business API, o número não é um detalhe de infra — é o ativo. Um número restrito derruba campanha, intake e notificação ao mesmo tempo. E o pior: quando o estrago aparece no dashboard, ele já aconteceu dias atrás, numa janela móvel que você não viu rodar.</p> <p>A boa notícia é que a Meta não bane do nada. Existe um sistema legível por trás disso — <strong>quality rating</strong>, <strong>messaging limits</strong> e <strong>status do número</strong> — e ele é governado por sinais que você controla no design do produto. Este é o playbook para ler esses sinais e proteger os números antes de a luz ficar vermelha.</p> <h2 id="quality-rating-o-termômetro-que-você-precisa-olhar">Quality rating: o termômetro que você precisa olhar</h2> <p>A Meta atribui a cada número um <strong>quality rating</strong> com três cores, visível no WhatsApp Manager:</p> <ul> <li><strong>Verde</strong> — qualidade alta.</li> <li><strong>Amarelo</strong> — qualidade média; sinal de alerta.</li> <li><strong>Vermelho</strong> — qualidade baixa; risco real de rebaixamento.</li> </ul> <p>A cor é calculada a partir de <strong>sinais dos usuários</strong> numa <strong>janela móvel</strong> (rolling window): bloqueios, denúncias e feedbacks de “não é útil” depois que a pessoa recebe sua mensagem. Não é o que você acha da sua mensagem — é o que o destinatário faz com ela.</p> <p>Dois pontos que confundem todo mundo:</p> <ol> <li><strong>É retroativo e defasado.</strong> A janela móvel significa que a cor de hoje reflete o comportamento dos últimos dias. Quando vira amarelo, o problema já está rodando.</li> <li><strong>Volume amplifica.</strong> Um punhado de denúncias num número que manda pouco pesa muito mais do que o mesmo número absoluto num número com tráfego alto.</li> </ol> <table> <thead> <tr> <th>Cor da qualidade</th> <th>O que significa</th> <th>O que fazer</th> </tr> </thead> <tbody> <tr> <td>🟢 Verde</td> <td>Qualidade alta, baixa fricção com usuários</td> <td>Manter o padrão; é hora segura para escalar volume gradualmente</td> </tr> <tr> <td>🟡 Amarelo</td> <td>Sinais de bloqueio/denúncia subindo</td> <td>Pausar campanhas frias, revisar opt-in e relevância, reduzir cadência</td> </tr> <tr> <td>🔴 Vermelho</td> <td>Qualidade baixa, número em risco</td> <td>Parar envios proativos, corrigir a causa raiz, deixar a janela “limpar”</td> </tr> </tbody> </table> <div class="mermaid" data-caption="Caminho do número: quality rating cai → Flagged → Restricted. Violações de política podem levar a ban."> stateDiagram-v2 [*] --&gt; Connected Connected --&gt; Flagged: qualidade cai Flagged --&gt; Connected: comportamento limpo Flagged --&gt; Restricted: qualidade vermelha Restricted --&gt; Connected: recuperação Connected --&gt; Banned: violação de política </div> <blockquote> <p>Quality rating não é uma nota de prova — é a média móvel da paciência dos seus destinatários. Trate cada bloqueio como dívida técnica que vence em dias.</p> </blockquote> <h2 id="messaging-limits-como-os-tiers-escalam-e-despencam">Messaging limits: como os tiers escalam (e despencam)</h2> <p>Além da cor, todo número tem um <strong>messaging limit</strong> — quantos <strong>contatos únicos</strong> você pode <strong>iniciar</strong> (business-initiated) numa janela de 24h. Isso escala por <strong>tiers</strong>, em função de qualidade e verificação de negócio.</p> <p>A progressão típica vai mais ou menos assim:</p> <ul> <li><strong>Tier inicial</strong> — na casa de <strong>250</strong> contatos únicos / 24h (novo número, sem verificação de negócio).</li> <li>Depois <strong>1K → 10K → 100K</strong> contatos únicos / 24h.</li> <li>E um teto efetivamente <strong>ilimitado</strong> no topo.</li> </ul> <blockquote> <p>Os números exatos de cada tier mudam e dependem da sua conta. Trate-os como ordem de grandeza, não como contrato — sempre confirme no WhatsApp Manager e na doc da Meta.</p> </blockquote> <p>O mecanismo importa mais que os números:</p> <ul> <li><strong>Subir é automático.</strong> Mantenha qualidade alta e bata um volume relevante dentro do tier atual, e a Meta promove o número sozinha.</li> <li><strong>Descer também.</strong> Qualidade baixa pode <strong>rebaixar</strong> o tier ou <strong>restringir</strong> o número, cortando seu teto de envio bem na hora em que você mais precisa dele.</li> <li><strong>Verificação de negócio é pré-requisito</strong> para destravar os tiers altos. Sem ela, você fica preso no degrau inicial por mais limpo que seja seu tráfego.</li> </ul> <p>A leitura para builders: o limite não é uma cota fixa que você “compra”. É um privilégio que sobe com bom comportamento e some com mau comportamento.</p> <div class="mermaid" data-caption="Tiers de messaging limits: volume sobe com qualidade alta e verificação de negócio; cai com qualidade baixa."> flowchart LR T0["~250 / 24h"] --&gt; T1["1K"] T1 --&gt; T2["10K"] T2 --&gt; T3["100K"] T3 --&gt; T4["Ilimitado"] T4 -.-&gt;|"qualidade cai"| T0 </div> <h2 id="status-do-número-o-caminho-até-o-ban">Status do número: o caminho até o ban</h2> <p>O quality rating é o sintoma; o <strong>status do número</strong> é o diagnóstico. Ele costuma andar por estes estados:</p> <ul> <li><strong>Connected</strong> — operando normalmente.</li> <li><strong>Flagged</strong> — a qualidade caiu e o número entrou em <strong>observação</strong>. Aqui você ainda envia, mas está sendo avaliado. É a sua janela de correção.</li> <li><strong>Restricted</strong> — o limite foi reduzido. Menos contatos únicos por 24h até a qualidade se recuperar.</li> </ul> <p>E, separado disso, <strong>violações repetidas de política</strong> (não só qualidade baixa) podem escalar para <strong>ban</strong>. Qualidade ruim restringe; violar política bane. São trilhos diferentes, e os dois levam ao mesmo abismo.</p> <p>A consequência prática: <strong>Flagged é o seu alarme</strong>, não Restricted. Se você só reage quando o limite já caiu, perdeu a janela barata de conserto.</p> <h2 id="o-que-realmente-queima-um-número">O que realmente queima um número</h2> <p>Quase todo ban ou rebaixamento rastreia para uma destas causas:</p> <ul> <li><strong>Mandar para quem não deu opt-in.</strong> A causa número um. Sem permissão, a pessoa bloqueia ou denuncia — e a janela móvel registra.</li> <li><strong>Lista comprada ou contato frio.</strong> Marketing para quem nunca te chamou é o atalho mais rápido para o vermelho.</li> <li><strong>Pico súbito de volume sem warm-up.</strong> Sair de 50 para 5.000 envios num dia parece spam para o sistema, mesmo que a lista seja limpa.</li> <li><strong>Template spam ou categorizado errado.</strong> Conteúdo promocional disfarçado de utilidade, ou template mal-categorizado, derruba engajamento e atrai denúncia.</li> <li><strong>Ignorar opt-out.</strong> Continuar mandando depois do “pare” é violação direta de política.</li> </ul> <p>Repare no padrão: nenhuma dessas é sobre a tecnologia. Todas são sobre <strong>expectativa do destinatário</strong>. O sistema da Meta é, no fundo, um proxy para “essa pessoa queria receber isso?”.</p> <h2 id="o-playbook-para-builders">O playbook para builders</h2> <p>Se você onboarda clientes ou opera múltiplos números, qualidade vira problema de <strong>engenharia de produto</strong>, não de operação manual:</p> <ul> <li><strong>Opt-in explícito por design.</strong> Desenhe o onboarding e os fluxos para <strong>coletar e registrar</strong> o consentimento. Guarde a prova. Opt-in não é checkbox de termos — é o que separa seu número do vermelho.</li> <li><strong>Warm-up gradual.</strong> Número novo começa devagar e sobe volume ao longo de dias/semanas, acompanhando o tier. Não force o degrau.</li> <li><strong>Mensagem relevante e esperada.</strong> A pessoa deve reconhecer por que está recebendo aquilo. Categorize o template corretamente e respeite a <strong>janela de 24h</strong> para conversas livres.</li> <li><strong>Opt-out fácil e respeitado.</strong> Saída de um toque, processada na hora. Barato de implementar, caríssimo de ignorar.</li> <li><strong>Monitore qualidade em escala.</strong> Não dá para olhar número por número no WhatsApp Manager quando são dezenas. Instrumente alertas para quando qualquer número virar amarelo — Flagged é o gatilho de ação.</li> <li><strong>Proteja o ativo do cliente.</strong> O número é dele, mas a reputação de quem construiu a integração também está em jogo. Trate cada número de cliente como você trataria o seu de produção.</li> </ul> <p>Um reforço que vale o esforço: <strong>número com verificação de negócio e selo</strong> tende a sofrer menos marcação e destrava os tiers altos. Vale entender os caminhos de verificação no post sobre <a href="/artigos/selo-azul-whatsapp-business-api-oficial-meta/">o selo azul no WhatsApp Business</a> antes de prometer escala para um cliente.</p> <h2 id="perguntas-frequentes">Perguntas frequentes</h2> <p><strong>Meu número virou amarelo. Vou ser banido?</strong> Não necessariamente. Amarelo é alerta, não sentença. É a janela para agir: pause campanhas frias, revise opt-in e relevância, reduza a cadência. Como a métrica usa janela móvel, parar a fonte do problema costuma recuperar a cor com o tempo. Vermelho ignorado é que vira restrição.</p> <p><strong>Quanto tempo leva para a qualidade se recuperar?</strong> Depende da janela móvel e do volume. Como o cálculo é deslizante, mensagens ruins “saem da conta” conforme envelhecem — desde que você não continue gerando novas denúncias. Não há botão de reset; é comportamento limpo somado ao tempo.</p> <p><strong>Posso pagar para subir de tier mais rápido?</strong> Não. O tier sobe por qualidade alta + volume relevante + verificação de negócio, de forma automática. O que você controla é qualidade e verificação; o resto é o sistema da Meta promovendo (ou rebaixando) o número.</p> <p><strong>Qual a diferença entre número Restricted e banido?</strong> Restricted é reversível: o limite caiu por qualidade baixa e volta a subir quando a qualidade se recupera. Ban é a consequência de violações de política — outro trilho, bem mais difícil de reverter. Por isso qualidade e conformidade são problemas separados, e os dois precisam de atenção.</p> <hr /> <p><em>Tiers, status e critérios da Meta mudam com frequência e variam por conta. Valide sempre na fonte oficial: <a href="https://developers.facebook.com/docs/whatsapp/messaging-limits/">Quality rating e messaging limits no WhatsApp Manager</a>.</em></p> <p><em>Conteúdo da comunidade WhatsApp Founders 🇧🇷 — independente, sem vínculo oficial com o WhatsApp ou a Meta.</em></p> 2026-06-23T00:00:00+00:00 2026-06-23T00:00:00+00:00 https://www.whatsappfounders.com.br/artigos/janela-24-horas-categorias-template-whatsapp/ Vitor Fontenele

Como a janela de 24h e as categorias de template (utilidade, marketing, autenticação) decidem o que você pode enviar e quanto paga na WhatsApp Business API. Guia direto para founders e builders.

<p>Tem duas variáveis que governam o que você pode enviar na <strong>WhatsApp Business API</strong> — e quanto isso custa. A primeira é a <strong>janela de atendimento de 24h</strong>. A segunda é a <strong>categoria do template</strong>. Entender as duas é a diferença entre um fluxo barato e uma fatura inflada no fim do mês.</p> <p>A maioria dos builders descobre isso tarde: depois que a Meta recategorizou um template e cobrou taxa de marketing onde era pra ser serviço. Este texto é o mapa pra você não cair nessa.</p> <h2 id="a-janela-de-24h-o-que-é">A janela de 24h: o que é</h2> <p>A <strong>janela de atendimento</strong> abre no momento em que o <strong>usuário envia uma mensagem</strong> para o seu número. A partir daí, você tem <strong>24 horas</strong> para responder com <strong>mensagens livres</strong> — texto, mídia, botões, o que precisar. São as chamadas <strong>session messages</strong>: conteúdo de formato livre, sem aprovação prévia.</p> <p>Quando essas 24h expiram — ou quando você quer iniciar a conversa sem que o usuário tenha falado primeiro — a regra muda. Fora da janela, você <strong>só</strong> consegue enviar <strong>message templates</strong> pré-aprovados pela Meta. Nada de texto solto. Se o template não foi aprovado, não sai.</p> <p>Por isso a janela é uma alavanca de design, não só uma restrição. Fluxo bem desenhado tende a <strong>manter a conversa dentro da janela</strong> sempre que possível — é onde você tem liberdade total de formato e o custo mais baixo.</p> <div class="mermaid" data-caption="Dentro da janela de 24h: mensagens livres. Fora dela: só template aprovado, com categoria que define o custo."> flowchart TD U["Usuário envia mensagem"] --&gt; W["Janela de 24h abre"] W --&gt; IN{"Dentro da janela?"} IN --&gt;|Sim| S["Session messages<br />texto, mídia, botões"] IN --&gt;|Não| T["Só template aprovado"] T --&gt; C{"Categoria"} C --&gt; UTL["Utility · transacional"] C --&gt; MKT["Marketing · promoção"] C --&gt; AUTH["Authentication · OTP"] </div> <h2 id="as-três-categorias-de-template">As três categorias de template</h2> <p>Desde a reorganização de 2023, todo template se encaixa em uma de três categorias. A Meta trata e <strong>precifica cada uma de forma diferente</strong>, então a escolha não é cosmética.</p> <ul> <li><strong>Utility (Utilidade):</strong> mensagem atrelada a uma <strong>transação ou evento</strong> específico — atualização de pedido, confirmação de pagamento, status de conta, agendamento. É a categoria de serviço.</li> <li><strong>Marketing:</strong> promoção, oferta, lançamento, reengajamento, qualquer coisa que empurre o usuário de volta. É a categoria mais cara e a mais fiscalizada.</li> <li><strong>Authentication (Autenticação):</strong> códigos <strong>OTP</strong> e verificação de login. Formato restrito, uso específico.</li> </ul> <p>A regra de ouro: <strong>categorize certo na criação.</strong> Se você marca como utilidade algo que claramente é promocional, a Meta <strong>recategoriza</strong> na revisão — e você passa a pagar taxa de marketing sem ter planejado.</p> <table> <thead> <tr> <th>Categoria</th> <th>Quando usar</th> <th>Exemplo</th> <th>Observação de cobrança</th> </tr> </thead> <tbody> <tr> <td>Utility (Utilidade)</td> <td>Atualização de uma transação/evento já em curso</td> <td>“Seu pedido #1234 saiu para entrega”</td> <td>Tende a ser a mais barata; em certos cenários, utilidade dentro da janela de 24h ficou gratuita</td> </tr> <tr> <td>Marketing</td> <td>Promoção, oferta, reengajamento, novidade</td> <td>“Volte e ganhe 20% off nesta semana”</td> <td>Categoria mais cara; recategorização errada cai aqui</td> </tr> <tr> <td>Authentication</td> <td>Código OTP / verificação de login</td> <td>“Seu código de verificação é 482913”</td> <td>Faixa própria; varia por país</td> </tr> </tbody> </table> <figure class="post__figure"> <img src="/assets/images/linkedin-posts/linkedin-post-02.png" alt="Resumo visual das categorias de template e janela de atendimento na API" width="1200" height="630" loading="lazy" decoding="async" /> <figcaption>A categoria certa no template certo é o maior controle de custo fora da janela de 24h.</figcaption> </figure> <h2 id="o-modelo-de-cobrança-e-por-que-não-dá-pra-cravar-número">O modelo de cobrança (e por que não dá pra cravar número)</h2> <p>Aqui é onde mais gente se confunde, então vamos pelo modelo — não por valores.</p> <p>A Meta <strong>migrou de cobrança por conversa para cobrança por mensagem</strong> (rollout ao longo de 2024–2025). Na prática, o que importa pra você:</p> <ul> <li>Mensagens de <strong>serviço dentro da janela de 24h</strong> tendem a ser as mais baratas — e, em determinados cenários, templates de <strong>utilidade dentro da janela ficaram gratuitos</strong> (isso muda em 1º/out/2026 — veja o aviso abaixo).</li> <li>Templates de <strong>marketing</strong> e <strong>autenticação</strong> têm taxas próprias, que <strong>variam por categoria e por país</strong>.</li> <li>Iniciar conversa fora da janela (template) custa mais do que responder dentro dela.</li> </ul> <blockquote> <p>Desenhe o fluxo pra resolver o máximo <strong>dentro da janela de 24h</strong> e use template <strong>só</strong> quando precisar iniciar ou reativar. A categoria certa no template certo é o seu maior controle de custo na API.</p> </blockquote> <blockquote> <p><strong>Atualização (jul/2026):</strong> a Meta anunciou que, a partir de <strong>1º de outubro de 2026</strong>, mensagens de <strong>serviço</strong> e de <strong>utilidade enviadas dentro da janela de 24h</strong> passam a ser cobradas <strong>por mensagem</strong> — hoje são gratuitas (a utilidade na janela não é cobrada desde 1º/jul/2025). A janela segue sendo a melhor alavanca de formato e experiência, mas deixa de ser “de graça” a partir dessa data. As tarifas específicas devem sair até 1º/set/2026.</p> </blockquote> <p>Os números mudam com frequência — a Meta revisa essa política mais de uma vez por ano. <strong>Não decore valores.</strong> Orce sempre conferindo a <a href="https://developers.facebook.com/docs/whatsapp/pricing/">tabela oficial de preços da Meta</a> vigente para o Brasil antes de fechar conta com cliente.</p> <h2 id="por-que-builder-precisa-se-importar">Por que builder precisa se importar</h2> <p>Duas razões, e as duas mexem direto no produto:</p> <p><strong>Custo.</strong> Cada template fora da janela é dinheiro. Multiplique por escala e a categoria escolhida vira linha relevante no CAC. Recategorização silenciosa da Meta é o vazamento clássico — você acha que está pagando utilidade e está pagando marketing.</p> <p><strong>Entregabilidade.</strong> Categoria errada não é só caro: aumenta atrito com a Meta, e template mal classificado entra na fila de problemas que leva a <strong>rejeição</strong> (veja <a href="/artigos/templates-whatsapp-rejeitados-meta-como-aprovar/">como aprovar templates rejeitados</a>) e, no limite, pressiona seu <a href="/artigos/quality-rating-evitar-numero-banido-whatsapp/">quality rating</a>.</p> <p>Na prática, o desenho de fluxo bom faz três coisas: provoca o usuário a iniciar (abrindo a janela), resolve o grosso da conversa <strong>dentro</strong> dela, e reserva template para os momentos certos — notificação transacional como <strong>utilidade</strong>, campanha como <strong>marketing</strong>, login como <strong>autenticação</strong>. Sem misturar.</p> <h2 id="checklist-rápido-antes-de-subir-um-template">Checklist rápido antes de subir um template</h2> <ul> <li>A mensagem está atrelada a uma transação real? Então é <strong>utilidade</strong> — e descreva o evento com clareza no corpo, pra Meta não confundir com promoção.</li> <li>Tem CTA promocional, desconto, “aproveite”? É <strong>marketing</strong>. Assuma e precifique como tal.</li> <li>É código de acesso? <strong>Autenticação</strong>, formato restrito.</li> <li>O opt-in do usuário está registrado? Sem opt-in, nem comece — é pré-requisito da categoria iniciada por você.</li> <li>Dá pra resolver isso <strong>dentro da janela</strong> em vez de mandar template? Se sim, faça — é mais barato e mais flexível.</li> </ul> <h2 id="perguntas-frequentes">Perguntas frequentes</h2> <p><strong>O que reabre a janela de 24h?</strong> Qualquer <strong>nova mensagem enviada pelo usuário</strong> para o seu número reinicia o relógio de 24 horas. Suas mensagens não reabrem a janela — só as dele.</p> <p><strong>Posso mandar texto livre fora da janela?</strong> Não. Fora das 24h, só <strong>template aprovado</strong>. Texto de formato livre (session message) é exclusivo de dentro da janela.</p> <p><strong>Por que minha conta foi cobrada como marketing se eu marquei utilidade?</strong> Porque a Meta <strong>recategoriza</strong> templates na revisão quando o conteúdo é promocional. Se tem oferta ou reengajamento no corpo, ela trata como marketing — independente do que você selecionou.</p> <p><strong>Template de utilidade é sempre grátis?</strong> Não generalize. Em <strong>certos cenários</strong> (notadamente utilidade dentro da janela de 24h) ficou gratuito desde 1º/jul/2025 — mas a Meta anunciou que, a partir de <strong>1º de outubro de 2026</strong>, essas mensagens (serviço e utilidade na janela) voltam a ser cobradas por mensagem. Confirme sempre na tabela oficial da Meta para o seu caso e país.</p> <hr /> <p><em>As regras de janela, categorias e cobrança são definidas pela Meta e mudam com frequência — valide os valores e o tratamento de cada categoria na fonte oficial: <a href="https://developers.facebook.com/docs/whatsapp/pricing/">tabela de preços da WhatsApp Business Platform</a>.</em></p> <p><em>Conteúdo da comunidade WhatsApp Founders 🇧🇷 — independente, sem vínculo oficial com o WhatsApp ou a Meta.</em></p> 2026-06-20T00:00:00+00:00 2026-06-20T00:00:00+00:00 https://www.whatsappfounders.com.br/artigos/embedded-signup-onboarding-whatsapp-business-api/ Vitor Fontenele

Como onboardar clientes na WhatsApp Business API com Embedded Signup: fluxo, pré-requisitos de Tech Provider, pontos de fricção e como reduzir abandono.

<p>Onboarding é conversão. Cada passo entre o cliente clicar “Conectar WhatsApp” e o número estar pronto para enviar mensagem é um ponto onde alguém desiste. Se o seu fluxo de ativação exige trocar print de Business Manager, criar WABA na mão e mandar o cliente verificar número por conta própria, você está perdendo gente que já queria pagar.</p> <p>O <strong>Embedded Signup</strong> é a resposta da Meta para isso: um fluxo completo de cadastro, embutido dentro do seu produto, que conecta a conta do cliente à WhatsApp Business API em minutos — sem ninguém sair da sua tela. Para Tech Providers e BSPs, é a diferença entre um onboarding de dias e um de cinco minutos.</p> <div class="mermaid" data-caption="Embedded Signup: do CTA ao callback com code e gravação do token no backend."> flowchart LR A["CTA Conectar"] --&gt; B["Facebook Login"] B --&gt; C{"Tem BM?"} C --&gt;|Sim| D["Escolhe BM"] C --&gt;|Não| E["Cria BM"] D --&gt; F["WABA"] E --&gt; F F --&gt; G["Número"] G --&gt; H["SMS / voz"] H --&gt; I["Callback + code"] I --&gt; J["Backend grava token"] </div> <h2 id="o-que-é-embedded-signup">O que é Embedded Signup</h2> <p>Embedded Signup é um fluxo da Meta baseado em <strong>Facebook Login</strong>, renderizado dentro da sua aplicação. Em uma única sessão, o cliente:</p> <ul> <li>cria ou seleciona o <strong>Business Portfolio</strong> (Business Manager);</li> <li>cria ou seleciona a <strong>WABA</strong> (WhatsApp Business Account);</li> <li>adiciona e verifica um número de telefone;</li> <li>concede ao seu app as permissões para gerenciar e enviar mensagens.</li> </ul> <p>No fim, o seu backend recebe via callback o <strong>WABA ID</strong> e o <strong>phone number ID</strong> do cliente. Você troca o <code class="language-plaintext highlighter-rouge">code</code> por um token, registra o número, e a operação está de pé.</p> <p>Ele substitui o onboarding manual — aquele de compartilhar BMs por convite, criar WABA na mão e ficar trocando IDs por e-mail. Tudo o que era fricção humana vira fluxo guiado, em contexto.</p> <blockquote> <p>Onboarding é a primeira métrica de produto que importa para um Tech Provider. Menos passos entre o clique e o número ativo significam mais clientes ativando — e o Embedded Signup existe exatamente para encurtar essa distância.</p> </blockquote> <h2 id="o-fluxo-passo-a-passo">O fluxo, passo a passo</h2> <p>Do ponto de vista do cliente, é assim que roda:</p> <ol> <li><strong>Clique no CTA.</strong> O cliente clica em “Conectar WhatsApp” no seu produto. O SDK do Facebook abre o diálogo de login.</li> <li><strong>Facebook Login.</strong> Ele autentica na conta Meta dele. Aqui é onde muita gente hesita — vale explicar que isso não dá acesso ao Facebook pessoal.</li> <li><strong>Business Portfolio.</strong> Seleciona um Business Manager existente ou cria um novo na hora.</li> <li><strong>WABA.</strong> Cria ou seleciona a WhatsApp Business Account sob esse portfolio.</li> <li><strong>Número de telefone.</strong> Adiciona o número que vai virar canal oficial.</li> <li><strong>Verificação.</strong> Confirma a posse do número por <strong>SMS ou ligação</strong>.</li> <li><strong>Permissões.</strong> Concede ao seu app o acesso para gerenciar a WABA e enviar/receber mensagens.</li> <li><strong>Callback.</strong> Seu app recebe o <code class="language-plaintext highlighter-rouge">code</code> e os identificadores (WABA ID, phone number ID). O backend troca o <code class="language-plaintext highlighter-rouge">code</code> por um token de sistema e <strong>registra o número</strong> para começar a operar.</li> </ol> <p>O passo 8 é seu, não do cliente — e é onde o onboarding de fato “termina”. Antes de registrar o número e enviar a primeira mensagem (via template aprovado), a conexão existe mas ainda não produz valor.</p> <figure class="post__figure"> <img src="/assets/images/linkedin-posts/linkedin-mapa-onboarding-bm-bg-01.png" alt="Etapas do onboarding com Business Manager e Embedded Signup" width="1200" height="630" loading="lazy" decoding="async" /> <figcaption>Cada passo do signup é um ponto de abandono — instrumente o funil para ver onde o cliente trava.</figcaption> </figure> <h3 id="coexistência-também-passa-por-aqui">Coexistência também passa por aqui</h3> <p>Se o cliente quer manter o WhatsApp Business no celular <strong>e</strong> usar a API no mesmo número, isso é Coexistência — e há variantes do Embedded Signup que conduzem esse caminho (tipicamente via QR Code, com requisitos de elegibilidade próprios). Vale entender o trade-off antes de escolher: veja <a href="/artigos/api-oficial-whatsapp-cloud-vs-coexistencia/">Cloud ou Coexistência</a> para decidir qual modelo oferecer no seu fluxo.</p> <h2 id="pré-requisitos-do-builder">Pré-requisitos do builder</h2> <p>Antes de colocar o Embedded Signup na frente do primeiro cliente, o seu lado precisa estar montado. Esse setup é feito <strong>uma vez</strong>, pela plataforma:</p> <table> <thead> <tr> <th>Pré-requisito</th> <th>O que é</th> </tr> </thead> <tbody> <tr> <td><strong>App Meta com produto WhatsApp</strong></td> <td>Um app do tipo <em>Business</em> no Meta for Developers, com o produto WhatsApp adicionado.</td> </tr> <tr> <td><strong>Configuração de Tech Provider</strong></td> <td>App vinculado a uma Business Manager verificada, configurado para onboardar terceiros.</td> </tr> <tr> <td><strong>Permissões</strong></td> <td><code class="language-plaintext highlighter-rouge">whatsapp_business_management</code> e <code class="language-plaintext highlighter-rouge">whatsapp_business_messaging</code> (e, na prática, <code class="language-plaintext highlighter-rouge">business_management</code> para acessar a BM do cliente).</td> </tr> <tr> <td><strong>Advanced Access</strong></td> <td>As permissões acima aprovadas em <strong>App Review</strong> — sem isso, o fluxo falha por falta de acesso.</td> </tr> <tr> <td><strong>Facebook Login for Business</strong></td> <td>Configurado no app, com o diálogo de login habilitado.</td> </tr> <tr> <td><strong>Configuration ID</strong></td> <td>Um <code class="language-plaintext highlighter-rouge">config_id</code> do Embedded Signup, criado em <em>Facebook Login &gt; Settings</em>, que você passa no <code class="language-plaintext highlighter-rouge">FB.login</code>.</td> </tr> </tbody> </table> <p>Detalhe que economiza semanas: <strong>peça todas as permissões de uma vez no App Review</strong>. Submissões fragmentadas atrasam aprovação e geram inconsistências. E se você ainda está decidindo se vai operar como Tech Provider, BSP ou Solution Partner, esse é o momento — o papel define o que você consegue fazer no fluxo.</p> <h2 id="onde-o-fluxo-trava--e-o-que-fazer">Onde o fluxo trava — e o que fazer</h2> <p>O Embedded Signup é guiado, mas não é à prova de fricção. Os pontos de abandono mais comuns:</p> <ul> <li><strong>Verificação de negócio pendente.</strong> Se a Business Manager do cliente não está verificada, certas ações ficam bloqueadas. Detecte cedo e oriente o cliente a concluir a verificação na própria BM antes de seguir.</li> <li><strong>SMS não chega.</strong> O código de verificação atrasa mais do que se espera. Ofereça <strong>verificação por ligação</strong> como fallback imediato e cheque DDI e portabilidade do número — número portado para outra operadora é causa clássica de SMS que some.</li> <li><strong>Confusão na seleção de Business Portfolio.</strong> Clientes com múltiplas BMs escolhem a errada. Se você já sabe qual é a correta, <strong>pré-preencha</strong> os dados do negócio no <code class="language-plaintext highlighter-rouge">extras</code> do fluxo.</li> <li><strong>Erro de permissão.</strong> Se o cliente não é admin da BM, o fluxo falha — às vezes silenciosamente. Detecte a ausência de <code class="language-plaintext highlighter-rouge">authResponse</code> e mostre uma mensagem clara: “Você precisa ser administrador do Business Manager para conectar o WhatsApp.” Esse erro também aparece quando faltou Advanced Access do <strong>seu</strong> lado.</li> <li><strong>Display name reprovado.</strong> O nome de exibição da WABA passa por revisão da Meta. Nome genérico demais, com promessa indevida ou que não bate com o negócio, é reprovado. Oriente o cliente a usar o nome real da empresa.</li> </ul> <p>Medir o funil é o que separa quem otimiza de quem chuta. Instrumente cada etapa do signup — login, seleção de BM, verificação, callback — e você vai ver exatamente onde o dinheiro vaza.</p> <h2 id="por-que-isso-é-problema-de-founder-não-só-de-engenharia">Por que isso é problema de founder, não só de engenharia</h2> <p>É tentador tratar o Embedded Signup como “mais uma integração”. Não é. É o ponto onde a sua promessa de produto encontra a realidade — e onde a maioria dos leads decide se fica ou some. Um fluxo de ativação que pede menos do cliente, falha com mensagens claras e tem fallback para cada erro comum converte mais. Ponto.</p> <p>Depois que o número conecta, o jogo continua: registrar o número, aprovar um template de boas-vindas e cuidar do quality rating para não acabar com número limitado ou banido. Mas nada disso acontece se o cliente travou no passo 4 do signup.</p> <h2 id="perguntas-frequentes">Perguntas frequentes</h2> <p><strong>Preciso de App Review aprovado para testar o Embedded Signup?</strong> Para o fluxo completo em produção, sim — as permissões de WhatsApp exigem Advanced Access via App Review. Em desenvolvimento, você consegue testar com contas e papéis associados ao app antes da aprovação. Confirme o estado atual das regras na doc oficial, porque a Meta muda os requisitos de acesso com frequência.</p> <p><strong>O cliente precisa ter uma Business Manager antes de começar?</strong> Não. O Embedded Signup permite <strong>criar</strong> o Business Portfolio durante o fluxo. Ter uma BM verificada acelera (e evita bloqueios em algumas ações), mas não é pré-condição para iniciar.</p> <p><strong>Posso pular criação de BM e WABA quando o cliente já tem tudo?</strong> Sim. Há uma variante de compartilhamento que assume que a WABA já existe e só conecta ela ao seu app — útil para reduzir passos com clientes que já estão na plataforma. O nome e o comportamento exato dessa opção podem mudar; valide na doc da Meta.</p> <p><strong>O Embedded Signup serve para Coexistência ou só para Cloud?</strong> Os dois cenários são endereçáveis por variantes do fluxo, mas com requisitos diferentes (Coexistência tem elegibilidade própria, normalmente via QR Code). A escolha do modelo é uma decisão de produto — veja o <a href="/artigos/api-oficial-whatsapp-cloud-vs-coexistencia/">comparativo Cloud vs Coexistência</a>.</p> <hr /> <p><em>A Meta atualiza o fluxo, as permissões e os requisitos de acesso do Embedded Signup com frequência. Antes de implementar, valide sempre na fonte oficial: <a href="https://developers.facebook.com/docs/whatsapp/embedded-signup">documentação de Embedded Signup da Meta</a>.</em></p> <p><em>Conteúdo da comunidade WhatsApp Founders 🇧🇷 — independente, sem vínculo oficial com o WhatsApp ou a Meta.</em></p> 2026-06-18T00:00:00+00:00 2026-06-18T00:00:00+00:00 https://www.whatsappfounders.com.br/artigos/tipos-parceiro-meta-bsp-tech-provider-solution-partner/ Vitor Fontenele

BSP, Tech Provider, Solution Partner e Meta Business Partner: o que cada papel faz na WhatsApp Business API, quem é dono do faturamento e como isso define seu modelo de negócio.

<p>Todo mundo que constrói na <strong>WhatsApp Business API</strong> no Brasil tropeça nos mesmos rótulos: BSP, Tech Provider, Solution Partner, Meta Business Partner. Eles soam como sinônimos em conversa de WhatsApp, mas representam papéis tecnicamente diferentes — e confundi-los faz você errar a coisa mais cara de errar: o seu próprio modelo de negócio.</p> <p>A pergunta não é “qual nome é mais bonito no LinkedIn”. É “quem é dono do faturamento, quem hospeda a API, e o que isso me obriga a fazer”. Esta é a separação prática desses papéis, do ponto de vista de quem vai operar — não de quem vai só citar a sigla numa apresentação.</p> <div class="mermaid" data-caption="Papéis de acesso vs selo: Solution Partner e Tech Provider operam a API; Meta Business Partner é reconhecimento de mercado."> flowchart TB subgraph acesso["Papéis de acesso à API"] SP(["Solution Partner<br />ex-BSP"]) TP(["Tech Provider"]) end subgraph selo["Reconhecimento"] MBP(["Meta Business Partner<br />selo no diretório"]) end SP --&gt;|"Meta fatura o parceiro"| CLI1["Cliente"] TP --&gt;|"Meta fatura o cliente direto"| CLI2["Cliente"] MBP -.-&gt;|"não provisiona API"| acesso </div> <figure class="post__figure"> <img src="/assets/images/linkedin-posts/linkedin-indicador-api-oficial.png" alt="Indicador visual de API Oficial do WhatsApp no ecossistema Meta" width="1200" height="630" loading="lazy" decoding="async" /> <figcaption>O papel que você assume define quem controla a WABA, a linha de crédito e o onboarding do cliente.</figcaption> </figure> <h2 id="por-que-isso-importa-para-quem-constrói">Por que isso importa para quem constrói</h2> <p>Definir seu papel no ecossistema Meta não é burocracia. Ele determina três coisas concretas:</p> <ul> <li><strong>Modelo de receita:</strong> você revende mensageria com margem, ou cobra integração/software e deixa a Meta faturar o cliente?</li> <li><strong>Responsabilidade operacional:</strong> de quem é a <strong>WABA</strong> (WhatsApp Business Account), de quem é a linha de crédito, quem responde quando a <strong>quality rating</strong> cai ou um número é banido?</li> <li><strong>Onboarding:</strong> você provisiona acessos manualmente, ou usa o <strong>Embedded Signup</strong> para o cliente conectar a própria conta?</li> </ul> <p>Errar isso significa, na prática, assumir risco de faturamento que não era seu, ou prometer ao cliente um controle de conta que você não tem.</p> <h2 id="solution-partner-o-antigo-bsp">Solution Partner (o antigo “BSP”)</h2> <p>Historicamente chamado de <strong>BSP — Business Solution Provider</strong>, hoje a Meta tende a usar <strong>Solution Partner</strong>. Na prática operacional, é o papel clássico de <strong>revenda de mensageria</strong>.</p> <p>O Solution Partner <strong>hospeda e revende</strong> o acesso à WhatsApp Business API. Ele gerencia as <strong>WABAs dos clientes</strong> dentro da própria estrutura e normalmente é dono do <strong>faturamento</strong>: a Meta fatura o parceiro, e o parceiro fatura os clientes. É comum o parceiro <strong>compartilhar a linha de crédito</strong> com os clientes que estão sob a sua conta.</p> <p>Esse é o modelo de quem quer ser uma plataforma de mensageria com margem sobre o volume. Você fica no meio do fluxo financeiro — o que dá controle e receita, mas também coloca a conta (literalmente) no seu nome.</p> <h2 id="tech-provider">Tech Provider</h2> <p>O <strong>Tech Provider</strong> constrói <strong>sobre a Cloud API</strong> para clientes, mas a relação financeira é invertida em relação ao Solution Partner.</p> <p>Aqui, <strong>o cliente é dono da WhatsApp Business Account e da linha de crédito/cobrança</strong>. A Meta cobra o negócio do cliente <strong>diretamente</strong> — o Tech Provider não fica no meio do faturamento de mensageria. O papel do Tech Provider é <strong>integrar</strong>: construir o software, conectar a API e onboardar clientes, tipicamente via <strong>Embedded Signup</strong>, onde o próprio cliente autoriza e conecta a sua conta em poucos passos.</p> <p>O ponto histórico que muita gente perde: foi a <strong>Cloud API</strong> (a API hospedada pela própria Meta) que tornou viável ser <strong>Tech Provider sem precisar ser um BSP completo</strong>. Antes, hospedar a infraestrutura era parte do pacote; com a Cloud API, a Meta hospeda, e você pode focar em software e integração sem carregar faturamento de mensageria nem operar servidores de mensagens.</p> <blockquote> <p>A pergunta que define seu papel não é “que selo eu tenho”, é “de quem é a WABA e de quem é a fatura”. Solution Partner fica no meio do dinheiro; Tech Provider deixa a Meta cobrar o cliente direto.</p> </blockquote> <h2 id="meta-business-partner">Meta Business Partner</h2> <p>Esse é o que mais gera confusão, então vale isolar: <strong>Meta Business Partner é um nível de reconhecimento/selo</strong> — um diretório de parceiros para empresas que batem critérios de performance. Abrange áreas além de mensageria (ads, e-commerce etc.).</p> <p>Ser listado como Meta Business Partner <strong>não é o mesmo que “ter acesso à API”</strong>. É reconhecimento de mercado, não uma credencial técnica de acesso. Você pode operar plenamente como Tech Provider ou Solution Partner sem o selo, e o selo sozinho não provisiona nada — ele sinaliza maturidade ao mercado.</p> <h2 id="comparativo-dos-papéis">Comparativo dos papéis</h2> <table> <thead> <tr> <th>Papel</th> <th>Dono do faturamento</th> <th>Hospeda a API</th> <th>Onboard via</th> <th>Modelo típico</th> </tr> </thead> <tbody> <tr> <td>Solution Partner (ex-BSP)</td> <td>O parceiro (Meta → parceiro → cliente)</td> <td>Sim (revende acesso)</td> <td>Provisionamento sob a conta do parceiro</td> <td>Revenda de mensageria com margem</td> </tr> <tr> <td>Tech Provider</td> <td>O cliente (Meta cobra direto)</td> <td>Não (usa a Cloud API da Meta)</td> <td>Embedded Signup</td> <td>Software/integração sobre Cloud API</td> </tr> <tr> <td>Meta Business Partner</td> <td>— (não é papel de acesso)</td> <td>—</td> <td>—</td> <td>Selo de reconhecimento no diretório</td> </tr> </tbody> </table> <p>A tabela acima é o resumo operacional. Os dois primeiros são papéis de <strong>acesso e operação</strong>; o terceiro é um <strong>selo</strong>. Misturar essas categorias é a origem da maior parte da confusão.</p> <h2 id="como-decidir-o-seu-modelo">Como decidir o seu modelo</h2> <p>Três perguntas resolvem quase tudo:</p> <h3 id="quem-é-dono-do-faturamento">Quem é dono do faturamento?</h3> <p>Se você quer ficar no meio do fluxo financeiro e cobrar margem sobre mensageria, está olhando para <strong>Solution Partner</strong>. Se prefere que a Meta cobre o cliente diretamente e você fatura software/serviço por fora, <strong>Tech Provider</strong>.</p> <h3 id="quem-é-dono-da-waba">Quem é dono da WABA?</h3> <p>No modelo Tech Provider, a WABA é do <strong>cliente</strong> — ele mantém o controle e a portabilidade da própria conta. No Solution Partner, a WABA tende a viver sob a estrutura do <strong>parceiro</strong>.</p> <h3 id="você-quer-hospedar-e-revender-mensageria">Você quer hospedar e revender mensageria?</h3> <p>Se a resposta é não — você quer construir produto, não operar uma revenda de mensagens — a Cloud API + papel de Tech Provider é o caminho mais leve. Se a resposta é sim, e a revenda com margem é o seu negócio, então o modelo de Solution Partner faz sentido.</p> <p>Independentemente do papel, a responsabilidade sobre <strong>saúde dos números</strong> continua sendo sua de algum jeito: como Tech Provider você orienta o cliente; como Solution Partner os números podem estar mais perto da sua conta. Em ambos, vale entender também como o número se conecta — o trade-off de <a href="/artigos/api-oficial-whatsapp-cloud-vs-coexistencia/">Cloud vs. Coexistência</a> e o que esperar do <a href="/artigos/selo-azul-whatsapp-business-api-oficial-meta/">selo azul na API Oficial</a> muda conforme o papel que você assume.</p> <h2 id="perguntas-frequentes">Perguntas frequentes</h2> <p><strong>BSP e Solution Partner são a mesma coisa?</strong> Na prática, sim — “Solution Partner” é a nomenclatura mais recente para o que o mercado ainda chama de <strong>BSP</strong>. A função (hospedar/revender acesso à API e gerenciar WABAs de clientes) é a mesma. Como os nomes de programa da Meta mudam, confirme o termo vigente na documentação oficial.</p> <p><strong>Preciso ser BSP/Solution Partner para usar a API?</strong> Não. Com a Cloud API você pode atuar como <strong>Tech Provider</strong> — integrando para clientes que são donos da própria WABA e da cobrança — sem montar uma operação completa de revenda de mensageria.</p> <p><strong>Meta Business Partner dá acesso à API?</strong> Não. É um <strong>selo de reconhecimento</strong> num diretório de parceiros, separado do acesso técnico. Dá credibilidade de mercado, não provisiona conta nem libera a API.</p> <p><strong>Como o cliente conecta a conta no modelo Tech Provider?</strong> Pelo <strong>Embedded Signup</strong>: um fluxo em que o cliente autoriza e conecta a própria WhatsApp Business Account em poucos passos, sem provisionamento manual do parceiro.</p> <hr /> <p><em>Os nomes e os tiers do programa de parceria da Meta evoluem com frequência (foi assim que “BSP” virou “Solution Partner”) — não trate sigla como fato fixo; confirme o papel, os requisitos e a nomenclatura atual na <a href="https://developers.facebook.com/docs/whatsapp">documentação oficial da WhatsApp Business Platform</a> e no diretório de parceiros da Meta.</em></p> <p><em>Conteúdo da comunidade WhatsApp Founders 🇧🇷 — independente, sem vínculo oficial com o WhatsApp ou a Meta.</em></p>