BSP, Tech Provider e Solution Partner: os tipos de parceiro Meta
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.
Todo mundo que constrói na WhatsApp Business API 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.
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.
ex-BSP"]) TP(["Tech Provider"]) end subgraph selo["Reconhecimento"] MBP(["Meta Business Partner
selo no diretório"]) end SP -->|"Meta fatura o parceiro"| CLI1["Cliente"] TP -->|"Meta fatura o cliente direto"| CLI2["Cliente"] MBP -.->|"não provisiona API"| acesso
Por que isso importa para quem constrói
Definir seu papel no ecossistema Meta não é burocracia. Ele determina três coisas concretas:
- Modelo de receita: você revende mensageria com margem, ou cobra integração/software e deixa a Meta faturar o cliente?
- Responsabilidade operacional: de quem é a WABA (WhatsApp Business Account), de quem é a linha de crédito, quem responde quando a quality rating cai ou um número é banido?
- Onboarding: você provisiona acessos manualmente, ou usa o Embedded Signup para o cliente conectar a própria conta?
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.
Solution Partner (o antigo “BSP”)
Historicamente chamado de BSP — Business Solution Provider, hoje a Meta tende a usar Solution Partner. Na prática operacional, é o papel clássico de revenda de mensageria.
O Solution Partner hospeda e revende o acesso à WhatsApp Business API. Ele gerencia as WABAs dos clientes dentro da própria estrutura e normalmente é dono do faturamento: a Meta fatura o parceiro, e o parceiro fatura os clientes. É comum o parceiro compartilhar a linha de crédito com os clientes que estão sob a sua conta.
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.
Tech Provider
O Tech Provider constrói sobre a Cloud API para clientes, mas a relação financeira é invertida em relação ao Solution Partner.
Aqui, o cliente é dono da WhatsApp Business Account e da linha de crédito/cobrança. A Meta cobra o negócio do cliente diretamente — o Tech Provider não fica no meio do faturamento de mensageria. O papel do Tech Provider é integrar: construir o software, conectar a API e onboardar clientes, tipicamente via Embedded Signup, onde o próprio cliente autoriza e conecta a sua conta em poucos passos.
O ponto histórico que muita gente perde: foi a Cloud API (a API hospedada pela própria Meta) que tornou viável ser Tech Provider sem precisar ser um BSP completo. 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.
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.
Meta Business Partner
Esse é o que mais gera confusão, então vale isolar: Meta Business Partner é um nível de reconhecimento/selo — um diretório de parceiros para empresas que batem critérios de performance. Abrange áreas além de mensageria (ads, e-commerce etc.).
Ser listado como Meta Business Partner não é o mesmo que “ter acesso à API”. É 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.
Comparativo dos papéis
| Papel | Dono do faturamento | Hospeda a API | Onboard via | Modelo típico |
|---|---|---|---|---|
| Solution Partner (ex-BSP) | O parceiro (Meta → parceiro → cliente) | Sim (revende acesso) | Provisionamento sob a conta do parceiro | Revenda de mensageria com margem |
| Tech Provider | O cliente (Meta cobra direto) | Não (usa a Cloud API da Meta) | Embedded Signup | Software/integração sobre Cloud API |
| Meta Business Partner | — (não é papel de acesso) | — | — | Selo de reconhecimento no diretório |
A tabela acima é o resumo operacional. Os dois primeiros são papéis de acesso e operação; o terceiro é um selo. Misturar essas categorias é a origem da maior parte da confusão.
Como decidir o seu modelo
Três perguntas resolvem quase tudo:
Quem é dono do faturamento?
Se você quer ficar no meio do fluxo financeiro e cobrar margem sobre mensageria, está olhando para Solution Partner. Se prefere que a Meta cobre o cliente diretamente e você fatura software/serviço por fora, Tech Provider.
Quem é dono da WABA?
No modelo Tech Provider, a WABA é do cliente — ele mantém o controle e a portabilidade da própria conta. No Solution Partner, a WABA tende a viver sob a estrutura do parceiro.
Você quer hospedar e revender mensageria?
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.
Independentemente do papel, a responsabilidade sobre saúde dos números 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 Cloud vs. Coexistência e o que esperar do selo azul na API Oficial muda conforme o papel que você assume.
Perguntas frequentes
BSP e Solution Partner são a mesma coisa? Na prática, sim — “Solution Partner” é a nomenclatura mais recente para o que o mercado ainda chama de BSP. 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.
Preciso ser BSP/Solution Partner para usar a API? Não. Com a Cloud API você pode atuar como Tech Provider — 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.
Meta Business Partner dá acesso à API? Não. É um selo de reconhecimento num diretório de parceiros, separado do acesso técnico. Dá credibilidade de mercado, não provisiona conta nem libera a API.
Como o cliente conecta a conta no modelo Tech Provider? Pelo Embedded Signup: um fluxo em que o cliente autoriza e conecta a própria WhatsApp Business Account em poucos passos, sem provisionamento manual do parceiro.
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 documentação oficial da WhatsApp Business Platform e no diretório de parceiros da Meta.
Conteúdo da comunidade WhatsApp Founders 🇧🇷 — independente, sem vínculo oficial com o WhatsApp ou a Meta.