database_validations[] 中的每个条目都是一份完整的数据库核验报告,即数据库核验节点针对一个签发国家/地区的一次运行。各个服务的登记系统核验结果位于该条目的 validations[] 子数组中。本页面介绍了其 JSON 结构,以便您解析各服务返回的匹配结果、登记系统源数据以及生物识别分数。

概述
每当工作流节点运行数据库核验功能时,都会生成一份数据库核验报告。database_validations[] 数组中的每个条目代表针对一个签发国家/地区的一次节点运行;如果该节点针对该国家/地区运行了多个服务(例如巴西的 CPF + CNH),则每个服务都会作为独立项显示在该条目的 validations[] 子数组中。每份报告包含:
- 整体功能
status:FeatureStatusChoices值(Not Finished、Approved、Declined、In Review)。 - 汇总
match_type(full_match、partial_match、no_match,或者当没有服务返回可用结果时为null),通过匹配方法跨服务聚合得出。 issuing_state(ISO 3166-1 alpha-3)以及衍生的validation_type(one_by_one、two_by_two或not_enabled,绝不为null)。screened_data区块:发送至登记系统的用户所提供数据。validations[]数组:每个产生结果的服务对应一个条目,包含目录中的service_id/service_name、供应商中立的outcome_code、可选的outcome_detail、逐字段的validation映射表以及从登记系统响应中提取的清洗后的source_data。errors[]数组:查询失败或跳过时的逐服务错误;没有错误时,该键会被完全省略。warnings[]数组:核验过程中触发的风险事件(请参阅数据库核验警告)。- 用于标识生成该报告的工作流图谱节点的
node_id(仅限 V3 会话)。
在 API 响应中的位置
该报告在GET /v3/session/{sessionId}/decision/ 中以 database_validations[] 形式出现,它始终是一个 JSON 数组,绝非单个对象。工作流图谱中的每个数据库核验节点都在该数组中对应一个条目;相应地,每个条目的 validations[] 子数组中包含产生结果的每个登记系统服务的一个条目。
null 值表示尚未运行任何数据库核验步骤。
数据模式
权威的逐字段模式位于数据模型页面。它由DatabaseValidationV3Serializer 生成。
状态值
status 使用标准的功能级枚举(参见状态枚举)— 参见状态枚举参考。该枚举还定义了 Resub Requested,但数据库核验在实际中不会生成该状态。
在此基础状态之上还会应用自定义的每个节点状态规则。有关可配置操作及其默认值,请参见数据库核验警告。
结果代码
validations[] 中的每个条目都包含一个独立于供应商的 outcome_code — 即 MATCH、PARTIAL_MATCH、NO_MATCH、DOCUMENT_NOT_FOUND、INVALID_DOCUMENT_FORMAT、INVALID_INPUT、MINOR_BLOCKED、DECEASED、BIOMETRIC_NO_MATCH、BIOMETRIC_IMAGE_UNUSABLE、INCONCLUSIVE、DOCUMENT_SUPERSEDED、REGISTRY_UNAVAILABLE、REGISTRY_ERROR 之一。请注意其中的区别:NO_MATCH 表示登记库明确未能确认数据;INCONCLUSIVE 表示登记库无法做出确切判定(应转入审核,而非拒绝);而 BIOMETRIC_IMAGE_UNUSABLE 属于技术性自拍照问题(需重新拍摄)— 与明确的 BIOMETRIC_NO_MATCH 不同。完整分类法及建议的处理方式请参见结果代码页面。
每个服务一个条目
validations[] 数组包含每个生成了结果 payload 的服务对应的一个条目(一个 validation 映射、source_data、outcome_code 或 outcome_detail)。如果您的工作流针对同一个国家/地区运行多个服务(例如巴西 CPF + 巴西 CNH),每个服务都会单独显示,并带有各自的 service_id、outcome_code 和 source_data。汇总的 match_type 会聚合所有服务的结果(任何完全匹配 → full_match;否则任何部分匹配 → partial_match;否则为 no_match),而 validation_type 则根据有多少个不同服务实现了完全匹配推导得出 — 参见匹配方式。
预签名图像 URL
source_data(photo、signature)和 screened_data(selfie、cnh_qr_code_image、document_image)中的图像字段以会过期的预签名 URL 形式返回 — 可通过重新调用决策 endpoint 来刷新。原始上游 payload 故意未通过 API 暴露。
示例
Approved — 巴西 CPF 状态查询 (Receita Federal)
Approved — 阿根廷 DNI 生物识别 (RENAPER)
对于阿根廷,该核验使用 RENAPER,并进行生物识别人脸比对。响应中包含face_match_score 以及登记库返回的其他身份字段。
In Review — 登记库无法运行
当没有服务返回可用结果时 — 必填字段缺失或格式错误,或者登记库无法访问 —match_type 保持为 null,validation_type 为 not_enabled,系统会发出 COULD_NOT_PERFORM_DATABASE_VALIDATION 警告,且该功能在数据得到修正前会转为 In Review。对于跳过的服务不收费。
相关内容
- 数据库核验概述 — API 端到端的工作方式以及支持的登记库。
- 匹配方式 — 1×1 / 2×2 结果(
validation_type: one_by_one/two_by_two)的推导方式。 - 结果代码 — 包含特定国家/地区详细代码的完整逐项结果分类法。
- 支持的国家/地区与服务 — 所有已上线的登记库、必填字段和每次调用价格。
- 数据库核验警告 — 当服务无法运行时系统显示的内容。
- 数据模型 — 数据库核验 — 权威的逐字段模式。