类型化请求
让收件人、发送方、内容和消息意图在每次 API 调用中明确。
开发者
拥有清晰状态机的消息 API。
一次请求、结构化事件、明确错误，以及让你有信心从沙箱进入生产的工具。
让状态机可见的开发者体验，从首次请求到生产流量都拥有可预测 API、有用错误和面向调试的工具。
打开沙箱POST /v1/messages200 OK
curl https://api.jando.io/v1/messages -H "Authorization: Bearer ..." -d '{"to":"+14155550123","type":"otp"}'
message_idmsg_2048
RESTAPI 契约
p95延迟可见
7核心事件状态
24/7Webhook 重放窗口
01 / API CONTRACT
小而清晰的接口，明确的状态机。
让请求保持简单，让响应真正有用。每个字段都应该帮助开发者决定下一步。
01
创建工作区
生成沙箱凭证、设置回调地址，并定义可检查流量的团队成员。
02
发送测试
使用最小请求，获得稳定消息 ID，并在运营商送达前检查验证结果。
03
消费事件
验证签名、持久化事件 ID，并在生产前让处理器具备幂等能力。
04
安全发布
注册发送方、设置限制、比较追踪，在不改变产品契约的情况下切换凭证。
02 / EVENT STREAM
让你的系统可以信任的事件。
01message.accepted+42ms
02message.screened+282ms
03message.sent+522ms
04message.delivered+762ms
HANDLER RULE
持久化 ID，验证签名，让重试安全。
Webhook 消费者应该保持简单，把复杂度交给追踪。
03 / TOOLING MAP
从测试走向真实流量所需的一切。
安全重试
用幂等键和错误分类只重试可恢复的问题。
Webhook 安全
验证签名、重放事件并隔离失败消费者。
SDK 友好模式
使用适合现有服务栈的 REST 和 JSON 约定。
追踪检查器
检查从请求接受到运营商回执的每次转换。
发布控制
用限制、审批和生产清单发布配置。
04 / BUILD QUESTIONS
在生产前消除不确定性。
首次集成需要多久？
基础沙箱发送只需一个 API 请求。进入生产还需要发送方注册、Webhook 处理和内部审批。
Webhook 事件可以重试吗？
可以。事件拥有稳定 ID，可重放恢复，不必重新创建消息。
API 请求失败后会怎样？
响应会说明问题属于校验、授权、策略、供应商还是临时上游状态。
工程和支持能看到同一条追踪吗？
可以。通过基于角色的访问，团队共享消息 ID，同时只看到工作区允许的字段。
05 / NEXT BUILD