Bird vs 360dialog
Bird vs 360dialog para WhatsApp
360dialog é um provedor exclusivo de WhatsApp e esta é a comparação onde esse foco se destaca. Eles passam o payload da Meta diretamente, publicam os seus preços e operam o seu próprio servidor MCP hospedado. Bird é uma plataforma onde WhatsApp é um canal entre vários, e um agente pode enviar por ele.
No que a 360dialog é excelente.
Onde Bird é diferente.
No que a 360dialog é excelente
O payload da Meta, inalterado. O corpo de envio deles é o formato de mensagem da Cloud API: messaging_product, recipient_type, to, type e o objeto correspondente ao type. Uma equipa que já tem código da Cloud API muda o host e o cabeçalho de autenticação e mantém o payload — o caminho de migração mais curto nesta comparação e algo que Bird não pode oferecer.
Lista de preços publicada, self-service. Cada nível é um valor mensal por número WhatsApp, com as taxas de conversação da Meta repassadas separadamente, e os níveis de parceiro publicam também as suas taxas de plataforma e por canal. É possível calcular o custo de uma implementação pelo site sem falar com ninguém.
WhatsApp é a empresa inteira. Sem e-mail, sem SMS, sem voz, e uma página de status que separa os seus próprios componentes dos da Meta. Se WhatsApp é o seu único canal e quer um fornecedor cujo roadmap não pode ser desviado para outro lado, esse foco é o argumento — e é real.
Onde Bird é diferente
Um agente que pode enviar a mensagem. Ambos operam um servidor MCP hospedado, e esta é a diferença entre eles: as ferramentas da 360dialog gerem templates, perfis e webhooks, e a documentação deles descreve-o a compor um exemplo de corpo JSON para envio através da sua Messaging API. As 43 ferramentas WhatsApp de Bird incluem o próprio envio e o registo de números.
Uma tentativa que não pode duplicar o envio. Um cabeçalho Idempotency-Key no envio torna a repetição segura. A referência de mensagens deles não documenta chave ou cabeçalho de idempotência, e no WhatsApp um duplicado abre uma segunda conversação faturável em vez de simplesmente se repetir.
Um SDK tipado em vez do envelope da Meta. Passar o formato da Cloud API significa herdar a sua ergonomia: messaging_product em cada pedido, e o tipo de conteúdo repetido tanto em type como no objeto ao lado. O envio de Bird é uma chamada tipada cujo corpo nomeia o conteúdo diretamente, em TypeScript, Python, Go ou PHP.
A matriz
Capacidade por capacidade.
Ambos são BSPs da Meta e ambos operam um servidor MCP hospedado, o que torna esta a comparação mais próxima da série no eixo em que Bird normalmente vence. Leia a linha do agente nas páginas de Twilio e Infobip: lá é uma vitória de Bird por razões diferentes, e aqui tudo se resume a uma coisa — se o agente pode enviar.
| Capability | Bird | 360dialog | Who wins? |
|---|---|---|---|
| Pedido de envio | JSON para /v1/whatsapp/messages no seu host regional com uma chave API bearer, e o corpo nomeia o tipo de conteúdo diretamente. | JSON para um endpoint de mensagens no host WABA deles com um cabeçalho D360-API-KEY. O corpo é o formato Cloud API da Meta: messaging_product, recipient_type, to, type e o objeto correspondente. | |
| Tentativas seguras | Um cabeçalho Idempotency-Key no envio torna a tentativa segura. | A referência de mensagens deles não documenta chave ou cabeçalho de idempotência, por isso uma tentativa após um timeout pode enviar duas vezes. | |
| O que um agente pode fazer | 43 ferramentas WhatsApp no servidor hospedado em mcp.bird.com, incluindo o próprio envio, o ciclo de vida de templates desde a submissão à Meta, registo e perfil de números, e estatísticas. | Um servidor hospedado em mcp.360dialog.com/mcp cujas ferramentas criam, pré-visualizam, listam e eliminam templates, definem o nome de exibição e perfil de um canal, configuram webhooks e leem contas, canais, saldo e faturas. A documentação deles descreve-o a produzir um exemplo de corpo JSON para envio através da sua Messaging API. | |
| Como uma ferramenta com permissão restrita se comporta | Uma ferramenta que a sua permissão não pode chamar permanece listada e é anotada com o scope necessário, e uma recusa responde com um step-up OAuth. Ocultá-la foi tentado e removido: tornava um scope em falta indistinguível de uma capacidade em falta, e os agentes tiravam a segunda conclusão. | Os scopes são escolhidos no momento da autorização e recusar um oculta as ferramentas correspondentes, para que um agente nunca veja uma ferramenta que não pode chamar. | |
| Tipos de conteúdo | Um corpo de envio seleciona texto, template, imagem, vídeo, áudio, sticker, documento, localização, interativo ou cartões de contacto. | Um endpoint de envio suporta a lista completa de tipos da Meta: text, image, audio, video, document, sticker, location, contacts, interactive, template e reaction. | |
| SDKs tipados | SDKs tipados para TypeScript, Python, Go e PHP, gerados a partir da API. | Não aparecem SDKs oficiais por linguagem no índice de documentação deles. Como o payload é da Meta, um cliente Cloud API existente funciona contra o host deles. | |
| Canais além de WhatsApp | SMS, e-mail, voz, Verify e Realtime estão sob o mesmo URL base e chave, por isso um segundo canal é outro endpoint em vez de outro fornecedor. | WhatsApp é o produto. RCS é restrito por contacto em vez de self-service, e não há e-mail, SMS ou voz. | |
| Preços publicados | As tarifas são publicadas por país na página de preços do WhatsApp. | Cada plano é publicado como um valor mensal por número, com as taxas de conversa da Meta repassadas separadamente e sem margem sobre elas. |
A mesma mensagem
Envio de um template do WhatsApp.
O pedido da 360dialog é o da Meta, e esse é exatamente o ponto: se já envia pela Cloud API, só o host e o cabeçalho de autenticação mudam. O da Bird é uma chamada tipada em que o tipo de conteúdo é o nome do campo em vez de um valor repetido ao lado do seu objeto, e aceita uma Idempotency-Key.
360dialog
const orderId = "ord_8f21";
const response = await fetch("https://waba-v2.360dialog.io/messages", {
method: "POST",
headers: {
"D360-API-KEY": process.env.D360_API_KEY!,
"Content-Type": "application/json",
},
body: JSON.stringify({
messaging_product: "whatsapp",
recipient_type: "individual",
to: "15551234567",
type: "template",
template: {
name: "order_shipped",
language: { code: "en_US" },
components: [
{ type: "body", parameters: [{ type: "text", text: orderId }] },
],
},
}),
});
const result = await response.json();
console.log(result.messages[0].id);
Bird
import { BirdClient } from "@messagebird/sdk";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
const orderId = "ord_8f21";
const { data, error } = await bird.whatsapp
.send(
{
from: "+13124495648",
to: "+15551234567",
template: {
slug: "order_shipped",
language: "en_US",
components: [{ type: "body", parameters: [{ type: "text", text: orderId }] }],
},
},
{ idempotencyKey: orderId },
)
.safe();
if (error) console.error(error.message);
else console.log(data.id, data.status);
Custo de migração
Moderado.
O envio é uma reescrita real em vez de uma renomeação, porque está a sair do envelope da Meta. messaging_product e recipient_type desaparecem, o tipo de conteúdo deixa de ser um valor repetido ao lado do seu objeto e passa a ser o próprio campo, e o cabeçalho D360-API-KEY torna-se uma chave bearer. Em troca, a chamada passa a ser tipada e um retry torna-se seguro.
O item de agendamento é da Meta e não de nenhum dos fornecedores. Os templates são aprovados com base na WhatsApp Business Account em que se encontram, por isso mudar de fornecedor significa submetê-los novamente e esperar. A Bird permite a criação, o versionamento por idioma e a submissão via API e como ferramentas de agentes, o que torna a resubmissão programável em vez de reescrita manualmente.
Perguntas que as pessoas realmente fazem
A Bird é uma boa alternativa à 360dialog?
Ambos têm um servidor MCP. Qual é a diferença real?
Qual lida melhor com uma permissão em falta?
Perco alguma coisa ao abandonar o formato de payload da Meta?
Próximos passos
O guia de envio é o melhor ponto de partida: cobre a chamada de envio e as regras de janela.