Bird vs Infobip
Bird vs Infobip：WhatsApp 对比
两者都是 Meta 商业解决方案提供商，都提供 WhatsApp API 和模板 API，因此这是一次架构层面的对比，而非覆盖范围的比较。Infobip 为每种消息类型提供独立端点；Bird 为所有类型提供统一端点，消息类型在请求体中指定。
Infobip 的优势所在。
Bird 的不同之处。
Infobip 的优势所在
端点即表明发送内容。在 Infobip 的出站 WhatsApp API 中，文本消息和模板消息使用不同路径，因此请求具有自描述性，负载不会包含端点不接受的组合。查看其集成即可知道发送的内容，无需阅读请求体。
Bird 尚未覆盖的广度。同一账户和基础 URL 可访问 WhatsApp、SMS、邮件、语音、RCS、Viber 等渠道，且其维护的五个 API 客户端支持 Java、C#、PHP、Go 和 Python。对于 Java 或 C# 技术栈的团队，Infobip 更为便利；使用 Bird 则需要直接调用 HTTP API。
按产品拆分的代理接口。十五个基于 HTTP 的远程 MCP 服务器，每个产品一个，通过 API 密钥或带范围发现的 OAuth 2.1 认证。仅访问 WhatsApp 就是一个简洁的端点，且限定于 WhatsApp 范围的代理无法触及账户的其他部分。
Bird 的不同之处
重试不会重复发送。在发送请求中添加 Idempotency-Key 头即可确保重试安全。Infobip 自动生成的 API 客户端在任何端点上都不携带幂等键或头，重复的 WhatsApp 消息不仅会开启第二个计费会话，还会打扰收件人。
一个发送端点，支持所有内容类型。文本、模板、图片、视频、音频、贴纸、文档、位置、互动消息和联系人名片均为同一请求中的字段。新增内容类型只需添加一个字段，而非新路径、新客户端方法和新调用点。
整个渠道通过一个代理连接。mcp.bird.com 上的单个托管服务器提供 43 项 WhatsApp 操作：发送消息、模板全生命周期（包括提交至 Meta）、号码注册与资料管理以及统计数据。一次连接，而非每个产品一次。
对比矩阵
逐项能力对比。
两者都是 Meta BSP，都通过 API 创作模板，因此真正决定差异的行项并不多。将代理行与 Twilio 页面对比：Bird 明显胜出，因为 Twilio 的服务器仅限于文档层面；而在这里则旗鼓相当，因为 Infobip 的服务器确实能操作账户。结论随对手而变，而非取决于我们自身。
| Capability | Bird | Infobip | Who wins? |
|---|---|---|---|
| 发送请求 | 向您区域主机上的 /v1/whatsapp/messages 发送 JSON，使用 Bearer API 密钥认证，请求体中指定内容类型。 | 向其出站 WhatsApp API 下按消息类型区分的路径发送 JSON，使用您的个性化基础 URL，API 密钥携带发送权限。 | |
| 安全重试 | 在发送请求中添加 Idempotency-Key 头即可确保重试安全。 | Infobip 基于自有规范生成的 API 客户端在任何端点上都不携带幂等键或头，因此超时后重试可能导致重复发送。 | |
| 新增内容类型 | 同一请求中的一个字段。一个端点即可承载文本、模板、图片、视频、音频、贴纸、文档、位置、互动消息和联系人名片。 | 每种消息类型对应不同端点，因此需要不同的客户端方法和调用点。 | |
| 模板创作与审批 | 通过 API 创建模板、按语言版本管理并提交至 Meta，每个步骤同时作为代理工具开放。 | Infobip 的 WhatsApp 服务管理 API 同样支持通过 API 创建和管理模板。 | |
| 代理接口 | mcp.bird.com 上的单个托管服务器承载 43 项 WhatsApp 操作，代理只需连接一次即可访问发送、模板、号码和统计功能。 | 十五个基于 HTTP 的远程 MCP 服务器，按产品拆分，通过 API 密钥或带范围发现的 OAuth 2.1 认证。WhatsApp 是其中之一，访问其他产品需要额外接入。 | |
| 投递与入站事件 | 工作区 Webhook 订阅您指定的 WhatsApp 事件类型，如 whatsapp.delivered、whatsapp.read 和 whatsapp.received，按 Standard Webhooks 规范签名。 | 每个配置对应一个 Webhook，投递报告也支持拉取，适合偏好轮询而非被动接收的场景。 | |
| 一个主机覆盖整个渠道 | 发送、模板、号码和事件共享同一基础 URL 和密钥，部署在您的区域主机上。 | 每个账户一个个性化基础 URL，承载所有产品，WhatsApp、SMS 等均为其下的路径。 | |
| SDK 语言 | 提供 TypeScript、Python、Go 和 PHP 的类型化 SDK，以及 Swift、Kotlin 和浏览器的实时客户端。 | 维护五个 API 客户端：Java、C#、PHP、Go 和 Python。Node 客户端位于单独的社区组织中，版本为 0.3.2，最后一次发布是 2023 年 11 月。 |
同一条消息
发送一条 WhatsApp 模板消息。
区别在于端点。Infobip 直接寻址模板路径，使请求具有自描述性；Bird 使用统一的消息端点，在请求体中指定模板名称——这意味着下一个内容类型只需更改一个字段，而无需调用新的端点。Bird 的发送还支持 Idempotency-Key。
Infobip
const response = await fetch("https://your-base-url.api.infobip.com/whatsapp/1/message/template", {
method: "POST",
headers: {
Authorization: `App ${process.env.INFOBIP_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
messages: [
{
from: "15557654321",
to: "15551234567",
content: {
templateName: "order_shipped",
language: "en_US",
templateData: { body: { placeholders: ["ord_8f21"] } },
},
},
],
}),
});
const result = await response.json();
console.log(result.messages[0].messageId, result.messages[0].status.name);
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);
迁移成本
低到中等。
双方都使用 JSON 和 Bearer 风格的密钥，因此字段可以直接对应：from 和 to 保持相同的名称，模板从路径移入请求体。工作量取决于您发送的消息类型数量，因为 Infobip 的每种类型对应不同端点，而这些都会合并到同一个 Bird 调用中——这是一种简化，而非重写。
排期相关的问题取决于 Meta 而非任何一家供应商。模板是在其所属的 WhatsApp Business Account 下审批的，因此更换服务商意味着需要重新提交并等待审批。Bird 支持通过 API 进行模板创作、按语言版本管理和提交，使重新提交过程可脚本化。