如何选择消息 API：CTO 选型清单

这份清单面向为短信、WhatsApp、RCS 及其他渠道选择消息 API 的 CTO、工程负责人和架构师。它把模糊的供应商比较，转化为具体的问题、你一个下午就能完成的测试，以及可以向财务和安全团队交代的评分表。

如果你已经选定了服务商，需要构建集成，请改读我们的消息 API 集成指南。本文讨论的是在那之前的决策。

CTO 应该从哪些方面评估消息 API？

评估那些影响生产结果的因素：消息是否送达、你能否看到发生了什么、集成能否经受故障、以及是否能保持合规。各家服务商的功能清单大同小异，但这些特性却不然。

API 是否覆盖了你需要的渠道？

寻找跨渠道统一的基础 URL、认证方案和送达状态模型。每个渠道各自集成，会成倍增加你要维护的代码，以及状态可能丢失的环节。

• 列出你未来两年的渠道， 而不仅仅是今天的。以短信验证码起步的团队，往往随后会加入 WhatsApp 模板，再是 RCS，然后是电子邮件或推送。
• 检查渠道的深度， 而不只是看图标。对于 WhatsApp，能否通过 API 管理模板、发送互动消息并跟踪审核进度？对于短信，是否支持双向消息、Unicode 和号码查询？
• 检查回退。 如果 WhatsApp 消息未送达，平台能否回退到 RCS 或短信，顺序能否按使用场景配置？我们的 WhatsApp、短信与 RCS 对比说明了各渠道的适用场景。

如何评判线路质量？

询问服务商如何到达你主要市场的每家运营商，然后自己去验证。线路质量决定消息是否到达、你的 Sender ID 能否保留，以及送达回执是否反映真实情况。

直连线路是指服务商依据涵盖应用到个人（A2P）流量的协议，连接运营商或其授权合作伙伴。灰色通道则通过并非为此设计的路径（例如消费类 SIM 卡连接）传送 A2P 流量。灰色通道在价目表上可能更便宜，但带有真实的风险：

• Sender ID 被替换为随机号码，破坏信任，也影响验证码自动填充的使用习惯；
• 运营商会检测并拦截流量，有时发生在活动进行到一半时；
• 送达回执可能由线路而不是网络生成，所以“已送达”不一定真的送达。

可以提出的问题：

1. 在我们的目的地国家和运营商中，你们对哪些是直连？
2. 你们如何处理各国的 Sender ID 报备？
3. 你们的送达回执来自哪里，是否会原样透传运营商的错误代码？
4. 当某条线路质量下降时，我们的流量会怎样？是否自动改道，并会通知我们吗？

然后进行测试：向每家主要运营商的真实手机发送消息，检查显示的 Sender ID，并把回执与手机上实际显示的情况对比。关于企业短信如何到达运营商的背景，请参阅什么是 A2P 短信。

送达回执和 Webhook 如何处理？

服务商应当将送达状态以跨渠道统一的规范化格式推送到你的 HTTPS 端点，并提供一种方式来补回你错过的事件。逐条轮询每条消息不是可持续的设计。

好的做法是：

• 有文档说明的状态列表。 例如 SUBMITTED、SENT、DELIVERED、READ、FAILED 和 REJECTED，并说明哪些是终态。我们的送达状态指南解释了每种状态在实践中的含义。
• 失败原因。 FAILED 或 REJECTED 状态在存在运营商或渠道原因时应当携带该原因。
• 补发。 如果你的端点宕机，你能否要求重推某个日期范围内的回执，或按收件人读取状态？
• 关于顺序和重复的坦诚说明。 事件可能乱序，也可能多次到达。明确说明这一点的文档，比忽略它的文档更值得信赖。
• 端点安全。 询问 Webhook 是否带签名。如果没有，服务商应该解释如何保护端点，例如仅限 HTTPS、不可猜测的路径、严格的请求体校验，以及在执行不可逆操作前确认状态。

应该期待怎样的认证与安全？

至少应做到：令牌通过 TLS 放在 Authorization 头中发送，绝不出现在 URL 里；有清晰的凭证轮换和吊销流程；以及经过独立审计的安全控制。Bearer 令牌在 RFC 6750 中定义，OWASP API 安全十大风险是与服务商逐项核对的好清单。

可以问：

• 令牌如何签发、限定范围和吊销？ 能否为每个服务或环境使用不同的令牌？泄露的令牌能多快被吊销？
• 凭证是否曾作为 URL 参数传递？ 一些老旧的 HTTP API 仍然在查询字符串中接受用户名和密码，它们会出现在日志里。新集成请避免这种做法。
• 是否提供 IP 白名单，适用于哪里？ 它在 SMPP bind 中很常见；请核实是否也适用于 REST。
• 哪些认证资质涵盖了该服务？ 索取证书或报告，而不只是一个图标，并检查适用范围。
• 消息内容存储在哪里，保存多久？ 这对数据保护审查很重要。

应该规划怎样的限流和吞吐量？

应当有公开的默认限额，在你超出时返回带 Retry-After 头的 429 Too Many Requests 响应（RFC 6585），并有就生产高峰协商更高上限的流程。没有文档的限制，会在你最大的一次活动中才被发现。

• 按接口询问限额： REST 请求、SMPP bind 和查询调用往往各有独立的限额。
• 检查批量接口。 发送一个包含收件人文件的请求，比发送成千上万个单独请求对限额更友好。
• 询问如何处理高峰。 限时抢购和事故告警需要与服务商一起规划，而不是靠运气。
• 规划好你这一侧。 在 API 前面放置队列和令牌桶限流器，可以让多个工作进程保持在你的配额之内。

我们的错误与限额参考展示了这类文档在实践中的样子。

SDK 和文档质量如何？

好的文档能让工程师无需提交工单，就发出一条真实消息、收到一个状态并处理一个错误。请索取 OpenAPI 文档；维护这份文档的服务商，可以提供生成的客户端、Postman 集合和准确的字段名。

质量的标志：

• 与线上 API 一致的 OpenAPI 3.x 规范；
• 至少一个持续维护的 SDK，以及其他语言的纯 HTTP 示例；
• 准确的请求字段名、带机器可读代码的错误响应体说明，以及响应示例；
• 以送达状态而不仅仅是“200 OK”结尾的快速入门；
• 对不支持的内容坦诚说明。

API 如何处理重试和重复消息？

一次发送请求可能在服务器上成功，但响应丢失，于是盲目重试会让客户收到两条相同的消息。请询问服务商期望你如何避免这种情况。

一些 API 接受幂等键：你随请求发送一个唯一值，使用相同值的重复请求会返回原来的结果。另一些（包括我们的 API）不接受幂等键；有文档说明的做法是：在发送前先将每次发送记录到你的数据库，保存返回的消息 ID，在超时后重发之前，先检查是否有已被接受的证据。只要有文档说明，两种方式都行得通。行不通的，是根本没有考虑过这个问题的服务商。错误与限额页面展示了发送前先记录的做法。

是否有安全的测试权限？

在任何流量触达客户之前，你应当能够用真实消息向自己掌控的号码测试。询问测试权限是什么样的：是模拟响应的沙箱，还是仅限已验证号码的真实发送。

模拟沙箱适用于单元测试，但很少能复现运营商的行为。向已验证号码的真实发送，能让你看到实际的 Sender ID 显示、编码和回执。询问从测试权限转为生产权限需要多长时间，因为一些国家的 Sender ID 审批取决于监管机构的时间表。

你是否需要 SMPP 选项？

第一天可能不需要，但之后也许需要。SMPP v3.4 是通过持久连接交换短信的电信协议，适合高并发、持续的大批量短信，以及聚合商和代理商。询问服务商是否提供基于 TLS 的 SMPP、bind 如何开通，以及是否使用与 REST 相同的线路。我们的 短信 API 与 SMPP 对比指南对两者做了详细比较。

AI 智能体能否安全地使用该 API？

如果你的团队使用 AI 助手或构建智能体，模型上下文协议（MCP）服务器可以让它们无需自定义胶水代码，就能发现并调用消息工具。询问智能体能做什么，以及拥有哪些权限。

可以问的问题：

• MCP 服务器是否使用与我们自有代码相同的令牌和权限运行？
• 我们能否只启用智能体所需的工具，例如只开放送达报告而不开放发送工具？
• 是否提供用于试验的临时密钥？
• 发送记录是否会出现在同样的送达报告中，以便我们审计智能体的行为？

关于这些控制的一个示例，请参阅我们的 MCP 服务器文档。

服务商应该提供哪些合规支持？

服务商应当在需要的地方帮助你报备 Sender ID，支持退订处理，并在公认的安全与隐私控制下处理数据。授权的责任仍由你承担；服务商应当让它做起来切实可行。

• Sender ID： 一些国家要求报备字母数字 Sender ID，有些国家还要求每条消息带有监管标识。参阅我们的阿联酋和沙特 Sender ID 报备指南。
• 授权： 询问双向短信中的退订如何被捕获，以及如何传递到你的系统。我们的授权指南介绍了相关义务。
• 数据保护： 询问数据处理协议、托管位置、保留期限和子处理方。

关于支持服务和 SLA，应该问什么？

把支持条款当作产品的一部分，并要求书面确认。不要比较销售材料中的醒目数字；比较的是合同作出了什么承诺。

• 事故如何被发现、通报和关闭？
• 支持覆盖哪些时段、时区和语言？
• 谁来处理运营商侧的问题，例如某个国家的 Sender ID 被拦截？
• 集成期间是否有指定的联系人或接入工程师？
• 协议承诺了什么，如何衡量，未兑现时会怎样？

定价有多透明？

你应当能够根据公开的价目表和你的发送量，估算月度账单。可以问：

• 价格是按消息、按分段，还是按已送达消息计算，不同渠道是否有差别？
• 哪些第三方费用是单独转嫁的，例如 Meta 的 WhatsApp 费用？
• 计费是预付费还是后付费，活动进行到一半额度用完会发生什么？
• 号码查询、Sender ID 报备和专用 SMPP bind 是否另行收费？

请记住，Unicode 和较长的消息会占用更多短信分段。我们的字符限制指南解释了为什么阿拉伯语活动可能比英语版本成本更高。

如何给服务商评分？

对每家入围的服务商进行相同的实际测试，然后在一张表中打分。按你自己的优先级为各项标准设置权重；下面的权重只是起点，而不是标准。

评分流程

1. 选出两到四家覆盖你的渠道和国家的服务商入围。
2. 向每家申请测试权限，并记录所需时间。
3. 对每家服务商运行下面的冒烟测试。
4. 向你主要市场每家主要运营商的真实手机发送消息。
5. 就上述每一节提出书面问题。
6. 每项标准按 1 到 5 分打分，乘以权重后相加。
7. 与安全、财务以及将负责运行集成的团队一起复核得分最高的两家。

一个简短的冒烟测试

每家服务商的文档都应该让你能完成类似的操作。下面是针对我们 API 的等效调用，与快速入门中展示的一致：

curl -X POST https://api.broadnet.me/sms/sendSms \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "OmniDemo",
    "destinationNumber": "447700900123",
    "message": "Your OmniDemo code is 482913",
    "messageType": "TEXT"
  }'

成功的调用会返回 200 OK，并以纯文本形式返回消息 ID。测试期间，再检查四件事：使用故意写错的令牌时会怎样（预期 401）、使用格式错误的号码时会怎样（预期带错误代码的 400）、发送阿拉伯语消息时会怎样（必须以 Unicode 发送；参阅短信 API 参考），以及 DELIVERED 状态是否到达你的 Webhook。

实操案例：一家金融科技公司选择验证码与提醒服务商

“Nakheel Pay”（虚构）是一款面向沙特阿拉伯和阿联酋的支付应用，现在需要短信验证码，一年内还需要 WhatsApp 交易提醒。

• 入围名单： 三家同时覆盖两个国家和两个渠道的服务商。
• 冒烟测试： 一家服务商几天内就开放了测试权限；另一家则要求先经过冗长的销售流程才能测试。这一点被记录在测试权限项下。
• 真机测试： 一家服务商在所有测试的运营商上，都显示已报备的 Sender ID；另一家则有一家运营商显示为数字号码。团队就其线路向该服务商提问，并在线路质量项上给予低分。
• 重复消息： 团队确认了各家服务商如何处理重试。一家接受幂等键；另一家文档说明了发送前先记录的做法。两种都可以接受；团队在自己的发送服务中一次性实现了这一模式。
• 安全评审： 安全团队检查了证书的适用范围和令牌吊销流程。
• 决策： 尽管另一家的短信标价略低，加权评分表仍倾向于拥有直连线路、规范化 Webhook 以及可供日后增长的 SMPP 选项的服务商。

选择消息 API 时的常见错误

• 仅凭单条消息价格做选择。 未送达的消息和被替换的 Sender ID，造成的损失比省下的钱更多。
• 只在模拟沙箱中测试。 运营商的行为只有在真实手机上才会显现。
• 忽视重复消息。 没有保护的重试循环会把验证码发送两次。
• 把“已发送”当作“已送达”。 要询问终态是如何回报的。
• 等到集成完成后才做安全评审， 那时更换服务商的成本很高。
• 接受口头承诺。 支持和服务条款应当写入合同。
• 本清单的局限： 它介绍的是良好实践，不构成法律意见。请向监管机构和你的服务商确认各国规则。

OmniChannels.ai 如何提供帮助

OmniChannels.ai 在 https://api.broadnet.me 提供一套统一的 REST API，覆盖短信、WhatsApp、RCS、Messenger、Instagram、Telegram、电子邮件和推送，采用 Bearer 令牌认证，记录在案的路径约 330 个，并提供 OpenAPI 3.1 规范和 TypeScript SDK @broadnet/cpaas-sdk。送达状态以统一格式送达你的 Webhook。大批量短信可使用基于 TLS 的 SMPP 3.4，MCP 服务器则让 AI 智能体能够使用同一套 API。流量通过 BroadNet 与 1,000 多家运营商和聚合商的直连线路传输。测试权限仅限你自己已验证的号码；请从开发者概览开始。