定义
Event Subscription（事件订阅）允许客户订阅 ICMP 平台产生的各类业务事件，如卡激活、用量告警、计费完成、状态变更等，通过 Webhook 实时推送至客户系统。客户无需轮询 API，即可实现系统联动、自动化运维与实时监控。
事件类型
典型可订阅事件包括：卡生命周期——激活成功、Suspension 暂停、Decommissioning 终止；用量与计费——流量超限告警、Overage 超量、套餐即将用尽、账单生成；连接状态——设备上线、离线、漫游切换；异常事件——异常消费、欺诈风险、运营商故障。客户可按需选择订阅的事件类型与过滤条件（如特定 ICCID、客户、区域）。
推送机制
Event Subscription 通常通过 Webhook 实现：客户在平台配置 Webhook URL 与密钥；平台在事件发生时向该 URL 发送 HTTP POST 请求，携带事件类型、时间戳、关联对象、载荷数据；客户系统接收后处理（如更新 CRM、触发告警、启动工单）。平台需支持重试、签名验证、失败告警，确保事件可靠送达。
在 ICMP 中的应用
达希物联 ICMP 支持 Event Subscription 与 Webhook 配置：客户可订阅多类事件，配置多个 Webhook 端点；支持按客户、按项目过滤；与 RESTful API、Audit Trail 配合，满足集成与审计需求。客户可将 ICMP 事件与自有运维系统、BI 平台、告警系统对接，实现端到端自动化。
订阅关系绑定的事件类型与过滤域
事件订阅是一份持续有效的登记：哪些事件类型、用什么条件过滤、推到哪一个地址。类型决定语义，例如卡启用、用量越过阈值、账单生成或连接中断。过滤域决定范围，例如只接收某一客户、某一批卡或某一个国家的事件。没有过滤域的订阅会收到租户下全部事件，接收方的容量和权限都会被放大。
订阅本身不是事件。事件是后来发生的事实，带有自己的标识、发生时间和对象。同一订阅可以对应多次推送。平台承诺的通常是至少送达一次，而不是恰好一次，也不是严格按发生顺序。接收方要按事件标识处理，不能假设下一条推送一定比上一条更新。停用订阅只停止后续推送，不会撤回已经发出的事件。
推送能被业务系统消费的前提
消费端要有可从平台访问的地址、校验签名的密钥、以及在处理完成后再返回成功的能力。签名用来确认推送来自平台且正文没有被改。时间戳用来拒绝放得太久的重放。处理逻辑必须能承受重复：同一事件标识第二次到达时，应返回成功并不再执行副作用，例如不要再次停卡或再次记账。先返回成功、再异步处理且可能失败，平台不会重试，事件就丢了。
地址不可达时，平台按约定重试，最终进入失败告警。接收方若在过载时仍返回成功，平台认为已经送达，数据却没有入库。过滤条件要和权限一致，不能订阅其他租户的卡。高频事件，例如每一次附着，不适合直接驱动人工流程，应先在平台侧聚合。与回调配合时，回调只是运输方式，订阅决定哪些事件上车。需要留痕的消费结果再写入审计追溯，推送日志本身代替不了业务动作记录。
未验签也未去重时的重复执行
不校验签名，任何知道地址的一方都可以伪造启用或停机事件，接收方会按假事件改自己的系统。不校验时间，截获的旧报文可以反复提交。不去重时，平台的正常重试会被当成新事件：阈值告警重试三次，客户系统就开出三张工单，或者把同一用量记三次。顺序假设也会出错，先处理了恢复事件，后到达的故障事件又把已经恢复的设备标成故障。
密钥轮换期间若没有重叠窗口，新旧签名都会失败，重试队列被打满。用事件里的卡号当作唯一键，同一张卡的不同事件会互相覆盖。正确的键是平台给出的事件标识。返回非成功状态码应只用于暂时失败，永久性错误，例如过滤条件写错，应在修正订阅后重新接收，而不是让平台无限重试同一地址。上线时用一条真实事件走通签名失败、重复投递和处理成功三种响应，并确认副作用只发生一次。不要在生产订阅里指向测试地址，测试环境处理生产事件会把真实的卡状态改掉。
订阅配置变更本身也要当成一次可追踪的动作。改过滤条件、轮换签名密钥、停用地址，若没有记录，事后无法解释为什么某一天的事件突然消失或突然被拒绝。密钥应有重叠期：新密钥开始验签之后，旧密钥仍接受一段时间，避免在途报文全部失败。接收方的成功标准是业务库已经记下事件标识，不是进程收到了字节。压测时用专用订阅和专用地址，不要把测试事件送进生产工单系统。生产地址返回的失败应告警到人，而不是只在平台里累加一个计数。