Bird vs Twilio
Bird vs Twilio:WhatsApp 对比
两者都是 Meta 商业解决方案提供商,因此消息到达 WhatsApp 的方式相同,不存在运营商差异的讨论。区别在于接口设计:Twilio 将 WhatsApp 放在您已有的 Messages API 的前缀之后,而 Bird 为其提供了独立的 API。
Twilio 的优势所在。
Bird 的不同之处。
Twilio 的优势所在
一个 API 覆盖两个渠道。 在 To 和 From 字段添加 whatsapp: 前缀,即可通过与 SMS 相同的 Messages API 发送 WhatsApp 消息,入站 webhook 保持与您现有 SMS 处理程序相同的数据格式。如果您已在使用 Twilio 的 SMS,添加 WhatsApp 只需加个前缀,而非新增一个集成。
十五年的知识积累。 Messages API 是该领域中被讨论最多的接口,几乎任何相关问题都已有公开答案,且辅助库覆盖的编程语言比 Bird 提供的更多。
带可视化编辑器的内容模板。 模板在 Content Template Builder 中创建,发送时通过 ID 引用,非工程人员无需触碰集成代码即可编写和编辑客户看到的消息。
Bird 的不同之处
代理运行整个渠道,而不仅仅是发送。 Bird 的托管 MCP 服务器支持 43 种 WhatsApp 操作,可在真实工作区中执行:发送消息、创建模板并提交至 Meta 审批、管理模板版本和语言、注册号码并设置资料,以及查看统计数据。
不会重复发送的安全重试。 发送时附带 Idempotency-Key 请求头,可确保重试安全。Twilio 的 Messages API 未提供幂等性请求头,重复的 WhatsApp 消息不仅会产生额外的会话费用,还会消耗客户的耐心。
一个请求体,支持所有内容类型。 发送请求在单个端点上以字段形式承载文本、模板、图片、视频、音频、贴纸、文档、位置、互动消息或联系人卡片,新增内容类型只需添加一个字段,而非新建一个调用。
对比矩阵
逐项功能对比。
两者都是 Meta BSP,因此投递能力不是比较的关键。Twilio 在渠道对称性和公开知识库规模上占优。Bird 在安全重试、单请求体承载所有内容类型,以及代理可操作的渠道功能范围上占优。对照 SMS 页面查看发送请求行:正是让 Twilio 的 WhatsApp 易于接入的架构设计,使其请求格式为 form-encoded。
| Capability | Bird | Twilio | Who wins? |
|---|---|---|---|
| 发送请求 | 使用 Bearer API 密钥,向区域主机上的 /v1/whatsapp/messages 发送 JSON 请求。WhatsApp 拥有独立的端点,而非与 SMS 共享。 | 使用 Account SID 和 auth token 通过 HTTP Basic 认证,向与 SMS 相同的 Messages.json 发送 form-encoded PascalCase 格式请求。通过在 To 和 From 字段添加 whatsapp: 前缀来选择 WhatsApp。 | |
| 安全重试 | 发送时附带 Idempotency-Key 请求头,确保重试安全。 | Messages API 未提供幂等性请求头,因此超时后重试可能导致重复发送。 | |
| 内容类型 | 单个发送请求体可选择文本、模板、图片、视频、音频、贴纸、文档、位置、互动消息或联系人卡片。 | 相同的 Messages 创建请求承载正文和媒体 URL,更丰富的内容通过 ID 引用的内容模板来实现。 | |
| 模板创建与审批 | 模板通过 API 创建、按语言版本管理并提交至 Meta 审批,且每个步骤都可作为 MCP 服务器上的工具调用。 | 模板在 Content Template Builder 中创建,发送时通过 ID 引用,控制台是主要操作界面。 | |
| 代理能力 | 托管在 mcp.bird.com 的服务器上提供 43 种 WhatsApp 操作,涵盖消息发送、模板生命周期、号码注册与资料设置以及统计查询。 | mcp.twilio.com/docs 无需账户即可访问,用 Twilio 的话说,仅索引公开的 API 规范,因此它帮助代理编写 Twilio 代码,而非操作账户。 | |
| 入站与投递事件 | 工作区 webhook 订阅您指定的 WhatsApp 事件类型,如 whatsapp.delivered、whatsapp.read 和 whatsapp.received,以符合 Standard Webhooks 签名规范的 JSON 格式投递。 | webhook 格式与入站 SMS 相同,To 和 From 设置为 WhatsApp 地址,媒体通过编号的 MediaUrl 字段传递。 | |
| 原生 WhatsApp 群组 | 通过 API 支持原生群组:创建和列出群组、管理成员和置顶消息、审批加入请求以及轮换邀请链接。发送时指定群组 ID,按群发消息计费和计量。该功能尚未出现在公开 API 参考文档或 SDK 中,也不是代理工具之一。 | Twilio 的 Conversations API 支持最多 50 人的多参与者 WhatsApp 聊天,已有文档且可立即使用。根据其示例说明,这是通过 WhatsApp 发送者实现的,而非原生 WhatsApp 群组。Programmable Messaging 的 WhatsApp 文档仅覆盖一对一消息。 | |
| 两个渠道共用一个集成 | SMS 和 WhatsApp 是同一基础 URL 和密钥下的独立端点,因此客户端是共享的,但调用点不同。 | 一个端点同时发送两者,因此现有的 SMS 集成只需更改地址前缀即可添加 WhatsApp。 |
同一条消息
发送一条 WhatsApp 模板消息。
前缀是一行代码中的架构差异:Twilio 在 SMS API 内处理 WhatsApp,Bird 则为其提供独立端点。Bird 的发送还接受 Idempotency-Key,这在 WhatsApp 上比 SMS 更重要,因为重复发送会开启第二个计费会话。
Twilio
import twilio from "twilio";
const client = twilio(process.env.TWILIO_ACCOUNT_SID!, process.env.TWILIO_AUTH_TOKEN!);
try {
const message = await client.messages.create({
from: "whatsapp:+15557654321",
to: "whatsapp:+15551234567",
contentSid: "HXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
contentVariables: JSON.stringify({ 1: "ord_8f21" }),
});
console.log(message.sid, message.status);
} catch (err) {
console.error(err);
}
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);
迁移成本
中等。
发送操作是重写而非重命名,因为数据结构确实不同:表单编码的 PascalCase 加 whatsapp: 前缀变为发送至 WhatsApp 端点的 JSON,通过 ID 引用的内容模板变为请求体中的模板对象。入站处理程序也会改变,从 SMS 格式的 webhook 变为工作区中对 WhatsApp 事件类型的订阅。
排期取决于 Meta 而非任何一家供应商。WhatsApp 号码注册在某个商业账户下,模板由 Meta 审批,因此请为迁移双方的审批时间做好规划,并在新模板通过审核前保持旧路径运行。