一次接入长什么样

一次完整的接入有三个部件。多数团队按下面的顺序搭，因为每一个都能在下一个到位之前单独验证。

三个部件

1 · 你的地址簿。 你希望被盯住的那些地址——入金地址、归集地址、金库地址。登记一次，此后在每个答复里以不透明的 customer_address_ref 出现。地址簿按客户加密，匹配在索引上完成，因此回答一次查询无需解密；跨客户读取不可表达。

2 · 变更流。 带游标的 GET /v1/exposure，加三个 webhook：exposure.match、exposure.revoked、coverage.health_changed。webhook 是变更流之上的延迟优化。变更流才是权威的一侧；漏收一条 webhook 永远不等于没事。

3 · 贷记闸门。 POST /v1/decide/deposit，每笔入金在贷记之前调用一次。这是唯一产生具有约束力裁决的接口，也是唯一一个失败模式既是我们的问题、也是你的问题的接口。

一个可以照着做的顺序

拿到密钥。确认 GET /v1/coverage 返回 200，读一遍你账户作用域内有哪些权威。
登记地址簿。确认 GET /v1/exposure 返回 200 与一个 next_cursor，即使 matches 是空的。
接好游标循环并持久化游标。先做它再做 webhook——webhook 出问题时，你要回落到的就是这条循环。
接 webhook 接收、签名校验，以及按 event_id 去重。
用开关把贷记闸门接上，先跑影子模式：调用、记录裁决、暂不据此行动。
把降级分支都建起来并测试。它们每一条都必须落在 HOLD。
打开开关。

第 6 步不是可以留到以后做的加固动作。它决定了这次接入到底值不值得做。

义务落在哪一侧

裁决内部的一切降级，都会以 HTTP 200 + verdict: HOLD + reason code 的形式回来——供应商超时、预算耗尽、名单陈旧、注册条目陈旧、覆盖盲区、裁决超时。这些你不需要自己识别，它们本身已经是裁决。

需要你自己处理的，是根本没有裁决的那种情况：5xx、连接错误、TLS 失败、DNS 失败，或你这一侧超时。没有裁决可读，正确行为是 HOLD。官方 SDK 默认这样实现，且不可通过配置关闭。如果你自己写客户端，这条由你实现。

托管还是私有部署

私有部署是一等交付形态，不是兜底选项：客户地址簿不离开客户环境。两种形态下契约完全一致——同样的路径、同样的 schema、同样的 fail-closed 语义——只有 base URL 不同。