一家商店可以就同一事件通知许多客户，同时为每条消息做个性化处理。每个收件人仍然需要授权许可和有效的投递路径。
向多个收件人发送时有什么不同？
你需要协调多次独立发送，而不是将一个请求视为完整的营销活动。
每个收件人可能有不同的目的地、发送方要求或同意状态。一个人的成功投递不能说明另一个人的手机情况。
个性化也会改变实际文本内容。更长的姓名或表情符号可能改变编码方式和分段数量。在估算计费量时，按完成后的消息正文计数。
应该使用广播还是 API 批量请求？
使用广播围绕受众、共享内容和发送计划协调活动。使用批量请求从您的应用提交独立消息。
SMS 活动工作流将受众准备、个性化、发布审核和收件人结果串联起来。批量端点提供更窄的操作：将多条独立请求一起接受。
批次标识符不能替代活动所有权、同意记录或发送计划。
Bird 如何接受批量请求？
您通过 POST /v1/sms/batches 提交 1 到 100 条独立消息。
将每个消息对象放入 messages 数组。一个包含 250 个收件人的活动至少需要三次请求，因为每个批次最多容纳 100 条。
Bird 在将任何条目排入队列之前会验证所有条目。一条无效消息会导致整个请求失败，返回 422。修复无效条目后重新提交该批次。
成功时，data 按提交顺序包含已接受的消息。summary.accepted_count 报告已接受的数量。批量参考文档描述了该响应。
将每个返回的消息标识符与其收件人关联保存。后续的投递事件属于这些独立消息，而非某个共享的批次结果。
批次提交成功是否意味着所有人都收到了消息？
202 响应表示 Bird 已接受这些消息进行处理。
计费、运营商提交和投递在之后发生。一条已接受的消息可能失败，而其他消息成功送达。根据每条消息的投递事件更新活动状态。
不要因为一个收件人失败就重新发送整个已接受的批次。调查该消息的错误，判断是否需要单独重试。
如何估算发送时间？
根据每个目的地发送路径适用的限制和容量，分别进行估算。
API 请求速率限制控制您提交工作的速度。投递吞吐量控制后续阶段。提高提交并发数无法消除运营商的限制。
计算容量前先确认计量单位。基于分段的限制会将一条多段消息计数多次。基于请求的限制则按批量调用计数。
Bird 将批量请求归入 sms_batch，与 sms_send 下的单条发送分开计算。请求速率限制指南说明了这些请求策略。SMS 吞吐量说明了独立的投递问题。
发布活动前应检查哪些事项？
检查每个收件人的同意状态、发送方资格和完整的消息内容。
发布排队工作时使用最新的退订状态。之前导出的列表可能包含此后已撤回许可的人。
在将收件人分批之前，先检查目的地的发送方要求。否则一条无效条目可能导致包含大量有效消息的批次被拒绝。
先从小范围群组开始。检查返回的结果，然后再扩大发送范围。这样可以在错误的发送方或消息触达整个列表之前更容易发现问题。
- 遵守目的地的规则和每个收件人的许可。
- 验证完整的消息正文。
- 计算消息的分段数。
- 在请求速率限制内提交批量请求。
- 按消息跟踪投递结果。逐条调查每个失败。
简而言之
每个收件人仍拥有独立的消息。
批次被接受并不意味着所有收件人共享同一个投递结果。
一个 Bird 批次最多包含 100 条消息。
使用批量请求发送独立的 API 消息。受众广播负责协调整个活动工作流。
验证针对整个批次进行。
一条无效消息会导致 Bird 在任何消息入队之前拒绝整个请求。
同意状态和发送方资格仍按个体检查。
在发布营销活动的每个部分时，重新检查权限和目的地要求。