Skip to main content
批量评分是 Qscore 的大批量模式:您无需逐份请求信用报告,而是提交一个批次的主体(目前为智利 RUT),CBPay 将异步为每个主体生成完整的 Qscore 报告。批次结束时,您将收到一个 webhook 和一封包含计数的邮件 — 绝不会按主体逐个通知。 典型用途:对现有组合进行重新评分(每月刷新债务人名单)、对供应商列表进行一次性尽职调查,或在新组合上线后补齐分数。对单个主体的临时查询,请继续使用单独报告

工作原理

批次会被立即接受(202),并由后台 worker 处理。每个条目都经过与单独报告完全相同的流水线 — 包括按需征信查询 — 因此批量分数与逐个查询得到的分数完全一致,使用相同的确定性模型(1–999,等级 A–E,主体无数据时为 SC)。

操作步骤

1

创建批次

通过 POST /v1/qscore/batches 提交主体,可以是 JSON 数组 CSV 文本(subjects_csv)。每个请求都必须携带 idempotency_key:使用相同键重放会返回原批次并带 idempotency_hit: true,绝不会重复创建批次或重复扣费。无效行会在创建时被拒绝并报告在 rejected_items 中 — 批次只处理有效行。doc_id 未通过该国校验位时产生 invalid_doc_id;同一批次内重复的 doc_id 产生 duplicate_in_batch(以其归一化形式报告)。无法识别的 subject_type 不会报错:该行会被接受,并按下方规则推断类型。
上述估算假设您账户配置了个人报告 4.00 USDT、公司报告 2.50 USDT 的费用:3 × 4.00 + 1 × 2.50 = 14.50。您的估算将反映账户实际配置的费用。
幂等重放会返回 200(而非 202),携带原批次和 idempotency_hit: true;rejected_items / rejected_count 明细仅在首次创建响应中包含。
2

等待完成信号

Worker 逐项处理。您无需轮询:批次到达终态时,您会收到恰好一个 risk_batch_completed webhook 和一封完成邮件,其中包含计数和指向您账户的链接。批次内的报告绝不会触发单独的 risk_report_ready webhook 或单份报告邮件 — 批次本身就是信号。如果您仍想轮询,GET /v1/qscore/batches/{id} 会返回实时计数(processed_itemssucceeded_itemsfailed_items)。
3

读取结果

逐条结果可通过 JSON(分页)或 CSV 导出(可直接用 Excel 打开)获取。
对于失败的条目,scorenull,行内携带 error_code / error_message:
CSV 导出(GET /v1/qscore/batches/{id}/results.csv)输出全部行并带 UTF-8 BOM(Excel 可正确打开),且包含每份报告的公开 verify_code。每个单元格都经过公式注入防护。可随时下载,即使批次仍处于 processing 状态 — 仍为 pending 的条目行其 score/band/verify_code 字段为空。
可见 CSV 表头跟随账户 locale;上面的示例显示单元格的原始键。每个 report_id 都是一份完整的单独报告:您可以使用标准的报告下载端点下载其 PDF,任何人都可以在 https://business.cbpayapp.com/verify/qscore/{verify_code} 验证其真实性。

列出并检索您的批次

GET /v1/qscore/batches 返回您账户的批次,按最新排序,支持分页(pagepage_size,默认 50,上限 200)并按 from / to(YYYY-MM-DD,组织时区,首尾均含)过滤:

批次与条目状态

批次(GET /v1/qscore/batches/{id}): 条目(GET /v1/qscore/batches/{id}/items):

计费

每个条目在 worker 处理时按您账户配置的独立费用(risk_report_personrisk_report_company)扣费。创建响应中的 estimated_fee_usdt 是有效条目的预先估算。
  • 幂等扣费:每个条目使用由批次和条目派生的确定性计费引用扣费,因此 worker 重启绝不会对条目重复扣费。
  • 自动退款:最终状态为 failed 的条目会在同一轮次中自动退款。您只需为实际生成的报告付费。
  • 扣费和退款会像其他 Qscore 费用一样出现在您的对账单中。

错误

Webhook:risk_batch_completed

每个批次恰好一个 webhook,在批次到达终态时投递给所属账户的订阅。使用事件类型 risk_batch_completed 订阅(参见 webhooks)。body 为下方的扁平对象,事件类型在请求头 X-Webhook-Event 中携带:
Webhook 仅携带计数 — 绝不包含分数或文档。请通过 GET /v1/qscore/batches/{id}/items 或 CSV 导出获取结果。完成邮件遵循同样的数据最小化原则:只有计数和一个链接。

常见问题

取决于批次大小以及每个主体的征信数据新鲜程度。每个条目都是一份完整报告(包括按需征信查询),请按每条几秒估算;1,000 个主体的批次通常在一小时内完成。您无需在线等待 — webhook 会在完成时通知您。
没有。Worker 运行的流水线与单独报告完全相同,模型版本也是同一个确定性版本。在同一时间点,对同一主体单独评分或在批次中评分,结果一致。
将其拆分为多个不超过 5,000 的批次,每个批次使用不同的 idempotency_key。各批次独立处理,并各自发送完成 webhook。
可以。逐行声明 subject_type,或让 API 按智利 RUT 号段推断。每个条目按其类型对应的费用计费。
处理过程具备崩溃安全性:worker 会从中断处恢复批次,确定性计费引用保证任何条目都不会被重复扣费。
当前版本不支持。已进入 processing 的批次会运行到结束;失败的条目会自动退款。
只有您的账户 — 其他账户会得到 404 not_found。批次绝不会跨组织可见。批次生成的单份报告是标准的 Qscore 报告,因此它们会出现在任何其他报告所在的位置(包括您组织的 org-admin 报告视图)。
最后修改于 2026年8月18日