Bird vs 360dialog

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 在那里因不同原因胜出,而这里的关键在于一点——代理能否直接发送消息。

CapabilityBird360dialogWho wins?
发送请求向区域主机上的 /v1/whatsapp/messages 发送 JSON,使用 Bearer API 密钥认证,请求体直接命名内容类型。向其 WABA 主机上的 messages 端点发送 JSON,使用 D360-API-KEY 头认证。请求体采用 Meta 的 Cloud API 结构:messaging_product、recipient_type、to、type 及对应对象。
360dialog
安全重试在发送请求中附加 Idempotency-Key 头即可确保重试安全。其消息参考文档中未提及幂等键或请求头,因此超时后重试可能导致重复发送。
代理能做什么托管服务器 mcp.bird.com 上有 43 个 WhatsApp 工具,包括发送消息本身、通过提交至 Meta 的模板全生命周期管理、号码注册与资料管理以及数据统计。托管服务器 mcp.360dialog.com/mcp 提供的工具可创建、预览、列出和删除模板,设置渠道显示名称和资料,配置 Webhook,以及读取账户、渠道、余额和发票信息。其文档描述的是通过 Messaging API 生成示例 JSON 请求体来发送消息。
受限工具的行为您的授权无法调用的工具仍会显示在列表中,并标注所需的权限范围,拒绝调用时会返回 OAuth 升级步骤。曾尝试过隐藏方式但已移除:它使权限缺失与能力缺失无法区分,而代理会得出后一种结论。权限范围在授权时选择,拒绝某项权限会隐藏对应工具,因此代理永远看不到它无法调用的工具。
360dialog
内容类型单个发送请求体可选择文本、模板、图片、视频、音频、贴纸、文档、位置、交互式消息或联系人卡片。单个发送端点承载 Meta 的完整类型列表:text、image、audio、video、document、sticker、location、contacts、interactive、template 和 reaction。
360dialog
类型化 SDK提供 TypeScript、Python、Go 和 PHP 的类型化 SDK,由 API 自动生成。其文档索引中未见官方语言 SDK。由于载荷采用 Meta 格式,现有的 Cloud API 客户端可直接对接其主机使用。
WhatsApp 之外的渠道SMS、邮件、语音、Verify 和 Realtime 共用同一基础 URL 和密钥,因此添加第二个渠道只是多一个端点,而非多一个供应商。WhatsApp 就是全部产品。RCS 需要联系方可开通,而非自助服务,且没有邮件、SMS 或语音。
公开定价费率按国家/地区公布在 WhatsApp 定价页面上。每个层级均以每个号码的月度费用公布,Meta 的对话费用单独透传,不加任何溢价。
360dialog

同一条消息

发送一条 WhatsApp 模板消息。

360dialog 的请求就是 Meta 的请求,这正是其卖点:如果您已通过 Cloud API 发送,只需更改主机和认证头。Bird 的请求是类型化调用,内容类型作为字段名而非在对象旁重复的值,并且支持 Idempotency-Key。

360dialog

360dialog

whatsapp.ts
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

whatsapp.ts
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 的好替代方案吗?
如果 WhatsApp 是您唯一的渠道且您已有 Meta Cloud API 代码,360dialog 在迁移成本上很难被超越:请求体无需更改,价格也是公开的。如果您需要安全可重试的发送、类型化 SDK、能直接发送消息而非仅组装请求的 Agent,或者后续需要第二个渠道而不想引入第二个供应商,Bird 是更好的选择。
两者都有 MCP 服务器。实际区别是什么?
范围不同。360dialog 的服务器负责账户操作:创建、预览、列出和删除模板,设置显示名称和资料,配置 Webhook,以及读取账户、渠道和发票信息。他们的文档中关于发送的描述是组装一个示例 JSON 请求体,通过其 Messaging API 发送。Bird 的 43 个 WhatsApp 工具涵盖发送本身和号码注册,因此 Agent 可以将消息完整地发送出去。
哪个更好地处理缺少权限的情况?
两者做出了相反的选择,但都有其道理。360dialog 会隐藏您未授权范围的工具,使 Agent 无法被诱导去尝试它看不到的操作,这在防范提示注入方面更强。Bird 保留工具列表,标注所需的权限范围,并在权限被拒绝时通过 OAuth 升级来响应,因为实践表明隐藏工具会使缺少权限与缺少功能无法区分,而 Agent 会得出后者的结论。选择您更愿意承担的风险。
离开 Meta 的请求体格式会有什么损失吗?
可移植性,这值得明确指出。Cloud API 请求体可以直接发送到 Meta,也可以发送到任何透传它的供应商,因此保持该格式意味着保留了一扇门。Bird 的发送使用自有的类型化格式,更易于编写和阅读,但无法原样迁移到另一个 BSP。如果供应商可移植性是核心需求,这反而是支持 360dialog 的理由。

从一个渠道开始。
准备好后,再添加其他渠道。

测试 API 密钥即刻可用。添加支付方式并验证发送者身份后,即可解锁生产环境。

正在使用 Claude Code、Cursor 或 Codex?复制一条设置提示,您的智能代理即可自动安装 Bird CLI 和相关技能。选择您的工具:

Cursor