只有团队能够说明超时、事件重复、供应商故障和数据不一致之后会发生什么，API 集成才算具备生产条件。确认实施范围前，可以使用以下清单。
适用范围
在开发新集成、更换供应商或接手没有文档的连接前，都应先完成这份检查。涉及支付、预约、库存或客户权限的流程尤其需要明确失败后的运行方式。
契约与责任
- 每项业务决策和字段由哪个系统负责？
- 请求、响应与错误格式是否有版本或文档？
- 使用什么时区、币种、小数和标识符格式？
- 有哪些限流、请求大小和维护窗口？
- 供应商修改契约时由谁负责沟通？
保存一组去除敏感信息的请求与响应样本。这样可以进行回归测试，而不必在每次测试时依赖供应商沙箱。
认证与密钥
- API 密钥与证书不得进入源代码。
- 明确轮换和过期行为。
- 只申请真正需要的权限范围。
- 解析业务内容前验证 Webhook 签名。
- 防止密钥与个人数据进入日志。
OAuth 集成还要明确处理用户撤销授权、刷新令牌失败和重新授权。
重试与幂等
所有可以重试的操作都需要幂等策略。超时不代表供应商执行失败；请求可能已经完成，只是响应在途中丢失。
使用稳定请求标识、有限指数退避和人工复核状态。永久性参数错误不应自动重试。
Webhook 处理
完成认证和事件持久化后尽快响应，把耗时工作异步处理。记录供应商事件 ID，遇到重复事件时不能再次执行业务动作。
必须假设事件可能延迟或乱序。状态变化要先检查当前状态，而不是直接覆盖。
对账
关键集成必须能够比较本地与供应商状态。支付、预约和库存系统应提供定时或手动对账，并拥有可见的异常队列。
如果没有对账，一次成功的 HTTP 响应就会成为两个系统仍然一致的唯一证据。
可观测性与支持
记录关联 ID、供应商 ID、状态变化和经过脱敏的错误上下文。针对持续失败、队列增长和密钥过期设置告警，而不是为每次临时错误报警。
最后明确谁查看告警、如何安全重放事件，以及何时联系供应商。没有运行处理流程的集成，即使代码正确也仍然没有完成。
实施前的判断点
在系统归属、重试策略、对账方式和支持责任都有明确答案前，不应确认实施范围。供应商沙箱可以证明连通，却不能证明上线后的运行过程完整。
相关服务
需要处理生产 API、支付和 Webhook 集成时，可查看API、支付与 Webhook 集成。