BroadNet同时提供HTTP（REST）短信API和SMPP绑定；如何选择取决于您的持续发送量和集成方式。 REST SMS API 是几乎所有现代工程团队的理想工具 —— 它对防火墙友好，不限编程语言，且易于集成。BroadNet 不对 REST 设置固定的单账户速率限制；当您需要维持每秒数百条消息的发送量、需要持久绑定，或处理任何需要二进制效率和完整 DLR 语义的工作负载时，SMPP 是最佳选择。大多数 BroadNet 客户从 REST 开始，并在业务量增长到合理规模时增加 SMPP 绑定。
12 行。拒绝虚假承诺。
标准相同，两列均适用。如果某行确实取决于具体用例，表格会注明。如果某一方明显是更好的工具，表格也会注明。
| 功能 | 列A SMS API (REST) HTTPS / JSON | 列B SMPP Short Message Peer-to-Peer 3.4 / 5.0 |
|---|---|---|
协议 | HTTPS POST + JSON | 二进制TCP，持久会话 |
默认端口 | 443 (TLS) | 2775（纯数字）；您的账户将提供TLS端口 |
身份验证 | Bearer token / API密钥 | 绑定时的system_id +密码 |
会话模型 | 无状态请求/响应 | 长效绑定收发器会话 |
吞吐量上限 | 无固定的单账户速率限制；根据您的流量进行配置 | 无固定的单账户速率限制；每节点最高30,000条短信/秒 |
幂等性 | 无幂等性请求头：请保留返回的消息ID，并在重新发送前检查状态 | 协议中不存在此类情况：sequence_number仅将响应与其请求进行配对 |
状态报告模式 | Webhook回调 | 在同一会话中的deliver_sm |
编码控制 | 自动（GSM-7 / UCS-2） | 手动data_coding参数 |
长短信处理 | 自动分段 | 手动UDH或message_payload |
入站MO处理 | Webhook回调 | 同一会话，deliver_sm |
集成工作量 | 从分钟（curl）到小时 | 1-2周（绑定逻辑、重试、会话保持） |
最佳适用场景 | Web应用、原型设计、中低业务量 | 持续高业务量、聚合商、电信运营商 |
每季度审核 · 请向以下地址提交更正： press@broadnet.me
bind_transceiver开启并验证会话bind_transceiver_resp会话已接受submit_sm发送消息submit_sm_resp已接受，已返回消息IDdeliver_sm状态报告或入站消息deliver_sm_resp已确认enquire_link空闲时的保活机制
哪种方案适合您的业务负载。
何时选择REST短信API
如果业务量中等、团队习惯于Web原生操作且集成周期较短，请选择REST。对于2026年的几乎所有CPaaS客户而言，REST是默认的现代化选择。
- 适用于应用型业务量，即每次 HTTPS 请求的开销不是瓶颈的情况。
- 适用于技术栈已原生支持HTTP的团队（Web应用、无服务器架构、移动后端）。
- 集成便捷性优于纯吞吐量效率的工作负载。
- 多渠道编排，将短信与WhatsApp、RCS及电子邮件协同使用。
何时选择SMPP
当业务涉及持续吞吐量、完全的DLR控制或聚合商模式运营时，请选择SMPP。SMPP比REST更古老且少见，但它是电信世界实际运行的协议，在大规模应用时效率极高。
- 当每秒持续发送数百条短信，或需要持久绑定的工作负载时，REST会开始产生连接建立成本。
- 需要对data_coding、有效期和message_payload进行完全控制的工作负载。
- 需要处理高量入站MO并在同一会话中使用deliver_sm的团队。
- 短信聚合商、电信运营商以及将消息服务作为核心业务职能的各类企业。
我们两者都提供，并鼓励客户从最能提高其团队效率的方式开始。对于大多数原生Web工程团队而言，这意味着使用REST。我们的POST /sms/sendSms端点、OpenAPI 3.1规范以及官方TypeScript SDK已涵盖了90%的客户需求，无需接触SMPP。
SMPP 成为正确选择的时机在于吞吐量阈值——即每秒持续发送数百条消息时——此时，每次请求的 HTTPS 握手开始占据主要的延迟预算，连接池问题也变得值得解决。届时，我们提供经过 TLS 加密的 SMPP 3.4 收发器绑定，无固定的单账户速率限制，可根据您的流量进行扩展，每节点最高30,000条短信/秒；主机、端口和凭据将在您的测试访问权限中提供。
我们也为需要更新的message_payload语义、广播处理或更清晰的状态报告的客户提供SMPP 5.0支持。实际上，全球95%的电信SMPP流量仍在使用3.4，因此我们将3.4作为默认版本。
一种常见的模式：使用REST用于发送单个OTP和通知的应用层代码，使用SMPP用于高吞吐量的营销活动和群发调度。两者都绑定到同一个SMSC，产生相同的状态报告，并按相同的价格表计费。客户可以根据需求灵活组合，无需额外考虑。
我们最常收到的问题。
SMPP究竟是什么？
+
SMPP究竟是什么？
短消息点对点协议（SMPP）——一种设计于20世纪90年代后期的二进制TCP协议，用于在SMSC与ESME（外部短消息实体，即应用程序）之间传递短信。它是聚合商与运营商之间承载大多数电信级A2P流量的协议。
SMPP的集成难度是否高于REST？
+
SMPP的集成难度是否高于REST？
难度显著增加。您需要处理长连接绑定会话、心跳（keepalive，即enquire_link）逻辑、序列号管理、编码识别以及绑定状态处理。大多数团队会使用现有的SMPP库——例如Java的Cloudhopper，Node的smpp.js，以及Java企业的jSMPP。
为什么高吞吐量发送者在2026年仍在使用SMPP？
+
为什么高吞吐量发送者在2026年仍在使用SMPP？
吞吐量效率。单个绑定的SMPP会话每个收发器每秒可推送1,000多条消息，而除非您仔细进行连接池管理，否则REST在每次请求时都需要进行新的TLS握手。对于持续的高吞吐量需求，二进制协议明显更高效。
BroadNet优先提供SMPP还是REST接口？
+
BroadNet优先提供SMPP还是REST接口？
两者皆可，新用户注册默认使用REST，而对于每秒维持数百条消息或需要持久绑定的负载，则可通过联系销售洽谈使用SMPP。两者背后均使用相同的SMSC；且适用相同的DLR语义。
那么SMPP 5.0呢？
+
那么SMPP 5.0呢？
我们支持。实际上，全球绝大多数A2P SMPP流量仍在使用3.4版本，除非客户明确要求使用5.0，否则我们将3.4作为新绑定的默认版本。
我可以在同一个账户中同时运行REST和SMPP吗？
+
我可以在同一个账户中同时运行REST和SMPP吗？
是的，针对同一个SMSC。大多数企业客户正是这样操作的——应用层代码使用REST，高吞吐量调度器使用SMPP。
状态报告的处理方式有何不同？
+
状态报告的处理方式有何不同？
REST会在您注册的URL接收Webhook回调。SMPP则在提交消息的同一会话中接收deliver_sm帧。两者在BroadNet层都携带相同的DLR字段和相同的状态报告负载。
选择REST而非SMPP会降低送达率吗？
+
选择REST而非SMPP会降低送达率吗？
不。无论选择哪个端点，同一条消息都会经过相同的SMSC和相同的运营商通道——状态报告（DLR）的准确性和通道完全一致。这纯粹是运营层面的选择，而非送达率的权衡。