Bird vs 360dialog
Bird vs 360dialog:WhatsApp 对比
360dialog 是一家 WhatsApp 专营服务商,这正是其专注优势最为突出的对比。他们直接透传 Meta 的原生载荷、公开价格,并运行自己的托管 MCP 服务器。Bird 是一个多渠道平台,WhatsApp 只是其中之一,代理可以通过它发送消息。
360dialog 的优势所在。
Bird 的不同之处。
360dialog 的优势所在
Meta 的载荷,原样透传。其发送请求体采用 Cloud API 的消息结构:messaging_product、recipient_type、to、type 及对应的 type 对象。已有 Cloud API 代码的团队只需更改主机地址和认证头,载荷保持不变——这是本次对比中最短的迁移路径,也是 Bird 无法提供的。
公开的价目表,自助服务。每个层级按每个 WhatsApp 号码收取月费,Meta 的对话费用单独透传,合作伙伴层级也公开其平台费和单渠道费用。您无需联系任何人,即可在网站上完成部署成本核算。
WhatsApp 就是整个公司。没有邮件、没有 SMS、没有语音,状态页将自身组件与 Meta 的组件分开展示。如果 WhatsApp 是您唯一的渠道,且您希望供应商的路线图不会被其他业务分散,这种专注本身就是最有力的论据,而且确实如此。
Bird 的不同之处
代理可以直接发送消息。双方都运行托管 MCP 服务器,区别在于:360dialog 的工具用于管理模板、资料和 Webhook,其文档描述的是通过 Messaging API 组装示例 JSON 请求体来发送消息。Bird 的 43 个 WhatsApp 工具包含发送本身和号码注册。
不会重复发送的安全重试。在发送请求中附加 Idempotency-Key 头即可确保重试安全。360dialog 的消息参考文档中未提及幂等键或请求头,而在 WhatsApp 上,重复发送会开启第二个计费对话,而非简单地重复消息。
类型化 SDK,而非 Meta 的信封格式。透传 Cloud API 的结构意味着继承其使用体验:每个请求都要带 messaging_product,内容类型在 type 和旁边的对象中重复出现。Bird 的发送是一次类型化调用,请求体直接命名内容类型,支持 TypeScript、Python、Go 或 PHP。
对比矩阵
逐项能力对比。
双方都是 Meta BSP,且都运行托管 MCP 服务器,这使得本次对比在 Bird 通常胜出的维度上最为接近。请对照 Twilio 和 Infobip 页面查看代理行:Bird 在那里因不同原因胜出,而这里的关键在于一点——代理能否直接发送消息。
| Capability | Bird | 360dialog | Who wins? |
|---|---|---|---|
| 发送请求 | 向区域主机上的 /v1/whatsapp/messages 发送 JSON,使用 Bearer API 密钥认证,请求体直接命名内容类型。 | 向其 WABA 主机上的 messages 端点发送 JSON,使用 D360-API-KEY 头认证。请求体采用 Meta 的 Cloud API 结构:messaging_product、recipient_type、to、type 及对应对象。 | |
| 安全重试 | 在发送请求中附加 Idempotency-Key 头即可确保重试安全。 | 其消息参考文档中未提及幂等键或请求头,因此超时后重试可能导致重复发送。 | |
| 代理能做什么 | 托管服务器 mcp.bird.com 上有 43 个 WhatsApp 工具,包括发送消息本身、通过提交至 Meta 的模板全生命周期管理、号码注册与资料管理以及数据统计。 | 托管服务器 mcp.360dialog.com/mcp 提供的工具可创建、预览、列出和删除模板,设置渠道显示名称和资料,配置 Webhook,以及读取账户、渠道、余额和发票信息。其文档描述的是通过 Messaging API 生成示例 JSON 请求体来发送消息。 | |
| 受限工具的行为 | 您的授权无法调用的工具仍会显示在列表中,并标注所需的权限范围,拒绝调用时会返回 OAuth 升级步骤。曾尝试过隐藏方式但已移除:它使权限缺失与能力缺失无法区分,而代理会得出后一种结论。 | 权限范围在授权时选择,拒绝某项权限会隐藏对应工具,因此代理永远看不到它无法调用的工具。 | |
| 内容类型 | 单个发送请求体可选择文本、模板、图片、视频、音频、贴纸、文档、位置、交互式消息或联系人卡片。 | 单个发送端点承载 Meta 的完整类型列表:text、image、audio、video、document、sticker、location、contacts、interactive、template 和 reaction。 | |
| 类型化 SDK | 提供 TypeScript、Python、Go 和 PHP 的类型化 SDK,由 API 自动生成。 | 其文档索引中未见官方语言 SDK。由于载荷采用 Meta 格式,现有的 Cloud API 客户端可直接对接其主机使用。 | |
| WhatsApp 之外的渠道 | SMS、邮件、语音、Verify 和 Realtime 共用同一基础 URL 和密钥,因此添加第二个渠道只是多一个端点,而非多一个供应商。 | WhatsApp 就是全部产品。RCS 需要联系方可开通,而非自助服务,且没有邮件、SMS 或语音。 | |
| 公开定价 | 费率按国家/地区公布在 WhatsApp 定价页面上。 | 每个层级均以每个号码的月度费用公布,Meta 的对话费用单独透传,不加任何溢价。 |
同一条消息
发送一条 WhatsApp 模板消息。
360dialog 的请求就是 Meta 的请求,这正是其卖点:如果您已通过 Cloud API 发送,只需更改主机和认证头。Bird 的请求是类型化调用,内容类型作为字段名而非在对象旁重复的值,并且支持 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);
迁移成本
中等。
发送调用是真正的重写而非重命名,因为您将离开 Meta 的封装。messaging_product 和 recipient_type 会消失,内容类型不再是在对象旁重复的值而变成字段本身,D360-API-KEY 头将变为 bearer 密钥。作为回报,调用变为类型化的,重试也变得安全。
排期问题在于 Meta 而非任何一家供应商。模板是在其所属的 WhatsApp Business 账户下审核通过的,因此更换供应商意味着重新提交并等待审批。Bird 支持通过 API 和 Agent 工具进行模板编写、按语言版本管理和提交,使重新提交可脚本化,而非手动重新输入。
大家真正会问的问题
Bird 是 360dialog 的好替代方案吗?
两者都有 MCP 服务器。实际区别是什么?
哪个更好地处理缺少权限的情况?
离开 Meta 的请求体格式会有什么损失吗?
下一步
建议从发送指南开始:它涵盖了发送调用和会话窗口规则。