定义业务事件
明确何时发送、向谁发送、需要什么上下文，以及什么情况下不应发送。
Developers / API integration
把消息旅程接入真实业务事件
Notify2You 的企业聚合接入服务连接业务系统、运营商与渠道路径，以消息对象、建议操作、SMS fallback 和 Webhook 状态形成完整集成工作流。
Message object
一个请求，明确主路径与备用内容
消息对象将 RCS 富媒体内容与 SMS fallback 分开表达，让团队在接入阶段统一审查两种体验。
- 由业务系统提供可追踪的外部引用
- 为建议操作定义明确类型与目标
- 只把必要数据放入消息对象
- 敏感凭据不进入消息正文或 Webhook
接入文档统一定义端点、鉴权、字段、限制、权限与能力范围。
message-object-pattern.json
{
"externalRef": "order_1042",
"recipient": "+{country}{number}",
"rcs": {
"title": "Your parcel arrives today",
"text": "Estimated 2:20–4:20 PM",
"actions": [
{ "type": "OPEN_URL", "label": "Track parcel" }
]
},
"fallback": {
"channel": "SMS",
"text": "Parcel due today. Track: {trusted_link}"
}
}Integration flow
先定义事件，再连接接口
把权限、安全、同意与异常路径放在集成设计前面，可以减少上线后的返工。
设计两种内容
分别编写 RCS 卡片与 SMS fallback，避免自动截断造成语义丢失。
建立身份与同意
确认发送者、收件人同意、退订和适用的通信或营销规则。
实现请求幂等
使用稳定的业务引用与幂等策略，降低重复发送风险。
验证 Webhook
校验签名、处理重复与乱序事件，并设计可观察的重试策略。
按目标条件验收
针对目标市场、设备、收件人条件与备用路径制定测试清单。
Webhook events
让消息状态回到你的业务系统
Webhook 承接状态变化与用户操作，并通过事件名称、签名校验、重试窗口和字段规范驱动业务处理。
- 快速确认收到事件，再异步处理业务逻辑
- 对事件 ID 去重，并容忍乱序到达
- 记录外部引用，便于与订单或预约关联
message-webhook.json
{
"eventId": "evt_1042_01",
"eventType": "message.action",
"occurredAt": "2026-08-29T09:41:00Z",
"data": {
"externalRef": "order_1042",
"action": "TRACK_PARCEL"
}
}
// Route verified actions into the business workflow.以环境化基础 URL、受控凭据和版本化文档组织生产 API 接入。
为开发、测试与生产环境分别管理基础 URL 和凭据，并在发布流程中控制切换。
消息可提示并引导用户，但支付、身份验证或账户变更应进入经过验证且适当安全的流程。
Discuss the integration
带着事件模型和 fallback 文案开始技术对话。
整理目标市场、发送场景、消息量级、身份与同意要求，以及期望的系统连接方式。