API 与 Webhook:相同的信任链，应用之外同样成立
Rexfin 的 REST API 和 Webhook 遵循与应用内相同的实际值与建模值区分规则以及引用规则，数字离开应用后不会变得更「可信」。
作者 The Rexfin team
一个在应用内可信、一旦离开应用就无法核实的数字，其实并不可信，它只是在有人盯着的时候看起来可信而已。Rexfin 的程序化接口建立在一条规则之上:任何一个数字能在屏幕上证明的事情，它在通过 API、Webhook 或结构化导出被拉取后也要能同样地证明。没有任何数字会在流出的过程中被“洗白”得看起来更干净。
每个数字流出时携带什么
API 或 Webhook 输出的每一个数值都被包裹在同一个信封里:它的货币和单位规模，它是实际值还是建模值，以及，关键的一点，当且仅当它是实际值时，才附带一个引用句柄。一个建模的预测值绝不会带着引用被输出，因为它在应用内部也从来不曾获得过引用。如果调用方的访问令牌没有被授权访问底层源文档，引用就根本无法解析，返回的是一个“受限”的失败关闭响应，而不是真实内容的简化版。这套模式(schema)本身就让实际值与建模值的区分无法被绕过:一个做集成的开发者不可能不小心写出把预测当作已提交数字来处理的代码，因为原本应该携带证明的字段根本不存在。
一套有文档、有版本管理的 REST API
REST 层是一个用 OpenAPI 描述、带版本管理的只读接口:报表、单个单元格、命名情景、某个模型当前的验证器判定结果,以及某个版本与上一版本之间的差异。它在设计上主要是只读的，这个接口不允许外部调用方把某个单元格或驱动因子写回你的模型，因为这项权限始终留在应用内部，由审计追踪记录谁改动了什么。访问通过 OAuth/OIDC 和受限范围的令牌进行，每个令牌的实际权限范围会被限定在令牌被授予的范围和发起请求者本人的访问控制所允许范围之间较窄的那一个，也就是说令牌永远不可能看到比发出它的人更多的内容，而且一旦会话中途失去访问权限，令牌会立即失效，而不是等到下次续期才失效。
Webhook:主动通知，而非轮询
订阅者注册关心的事件，而不是按计划反复轰炸 API,这些事件包括某个周期结账完成、某份董事会材料完成、某个版本发布，或者验证器关口在一次导出尝试中通过或未通过。每次投递都经过签名，接收方可以确认它确实来自 Rexfin,并以至少一次投递、带有稳定的事件 ID 的方式送达，因此重复投递可以被识别，而不是被静默地处理两次。宕机的订阅端点会以退避策略重试，而不是无限次轰炸，过往的投递记录会保留在列表中并可重新拉取，如果你需要重新获取某一条。verifier.failed 这个 Webhook 尤其值得一提，它传达的正是应用内部展示的“该模型不能被信任用于导出”这个同样的信号，并把这个信号带给任何需要知道它的下游流程，不需要任何人先去检查界面。
只有模型对得上账才会流出的结构化导出
除了人类可读的董事会材料,Rexfin 还能生成机器可消费的导出格式，包括标记到与报表相同分类体系(taxonomy)的 iXBRL,以及扁平的 JSON 和 CSV,供监管机构、交易所申报系统或并表流程下游摄取使用。这些导出的门槛与董事会材料的门槛完全一致:一个不平衡、未完成对账的模型无法生成导出文件。一个对不上账的模型生成结构化导出，正是这整套规范存在的目的所要防止的失败情形，因此这道关口在这里同样适用，不只是适用于人类阅读的文档。
这适合谁
这适合那些已经拥有商业智能(BI)技术栈、并表系统或内部流程，希望 Rexfin 的数字能够流入其中而不需要任何人把董事会材料重新打字录入到电子表格里的团队，也适合任何需要下游系统在模型对账成功或失败的那一刻就知道的场景。如果你目前的集成方案还是靠有人导出 PDF 再重新录入，这套 API 会用一份记录在文档中的契约来取代它，并携带与应用相同的保证。