sumsub-create-level

Sumsub — 创建 Level

根据简洁的规范构建 ApplicantLevel JSON 负载，将其 POST（或 PATCH）到 Sumsub API，并报告生成的 name / id。

端点

方法	路径	使用时机
POST	/resources/applicants/-/levels	创建新级别。请求体不得包含 id 或 key——由服务器分配。
PATCH	/resources/applicants/-/levels	更新现有级别（在请求体中通过 id 指定）。
GET	/resources/applicants/-/levels/{id}	读取单个级别。使用此接口验证实际写入的内容（租户限制可能会静默丢弃某些字段），或根据已知 id 查找 name。
GET	/resources/applicants/-/levels	列出所有级别（创建重复级别之前，使用此接口查找可复用的现有级别）。

请求体：ApplicantLevel。返回已保存的级别，包含 id、createdAt 和审计记录。

身份验证 — App Token + 密钥（仅限沙盒）

此技能会调用 Sumsub 公共 API，并根据 身份验证参考为每个请求签名。 完整的工作原理说明见 sumsub-api-auth 技能——如果遇到 401 Invalid signature，请阅读该说明。

⚠️ 仅限沙盒令牌。 请勿在此接受或使用生产环境的 App Token——创建级别会在工作区中可见并产生写入操作。如果用户提供生产令牌，请拒绝并要求其前往 https://cockpit.sumsub.com/checkus/home?sbx=true 生成一组沙盒凭据（Connect Sumsub to your AI agent -> Build & configure -> Generate token）。令牌和密钥只显示一次——关闭对话框前请复制两者。辅助脚本会强制执行此要求——它会拒绝不以 sbx: 开头的令牌。

变量	示例
SUMSUB_APP_TOKEN	sbx:... — 来自控制面板的沙盒 App Token。
SUMSUB_SECRET_KEY	创建令牌时显示一次的配对密钥。
SUMSUB_BASE	可选。默认值为 https://api.sumsub.com。

如果用户已在对话中提供凭据，请重复使用；否则，在运行前询问一次。切勿复述密钥。

流程

0. 获取租户权益。 调用 sumsub-check-permissions 技能并解析 JSON 结果。保存 allowedChecks 映射（其键为已启用的权益）；在第 2 步以及下方的权益部分进行所有功能门控检查时都使用此映射。务必先执行此操作。

1. 检查现有实体。 在创建任何内容之前，列出现有的级别、POA 预设和问卷（GET 对应的列表端点）。如果已有匹配实体，请提出复用其 id 并跳过 POST；服务器每次 POST 都会创建重复项，不会按名称去重。

2. 将用户的请求转换为下方的精简规范——名称、申请人类型，以及按 WebSDK 流程中预期显示顺序排列的文档集步骤列表。如果请求涉及数据库／非文档验证，请先通过 sumsub-check-databases 解析来源（见数据库／非文档验证）。

3. 验证——确认每个 type 都是有效的 IdDocSetType，每个 QUESTIONNAIRE 步骤的 questionnaireDefId 都指向现有问卷，每个 PROOF_OF_RESIDENCE* 步骤都具有 poaPresetId／poaStepSettingsId（如果缺少，服务器会拒绝该级别——如果不存在预设，请先运行 sumsub-create-poa-preset），每个 COMPANY 步骤都至少有一个命名的子步骤。使用第 0 步中的 allowedChecks 键，拒绝任何不在其中的权益门控功能。

4. 生成载荷——将规范通过标准输入传给 ${CLAUDE_SKILL_DIR}/scripts/build_level.py → 从标准输出获取完整载荷。

5. 向用户展示解析后的载荷，并在首次 POST 前征求明确确认。

6. 创建还是更新：

   • 新建级别——通过 ${CLAUDE_SKILL_DIR}/scripts/post_level.sh 执行 POST。返回响应正文和 HTTP 状态。
   • 更新现有级别——通过 ${CLAUDE_SKILL_DIR}/scripts/get_level.sh 获取当前状态，让用户查看差异，然后通过 ${CLAUDE_SKILL_DIR}/scripts/patch_level.sh 执行 PATCH。传给 build_level.py 的规范必须包含 id: <level-id>——构建器会将其保留在载荷中，PATCH 会拒绝不包含该字段的请求正文。PATCH 会整体替换 requiredIdDocs.docSets 数组——发送的每个 docSet 都必须包含完整的预期状态，因为服务器会清除 docSet 中省略的字段。将 GET 响应中的保留值复制到 PATCH 规范中。

7. 再次 GET 该级别——通过 ${CLAUDE_SKILL_DIR}/scripts/get_level.sh 获取并与已发送内容对比——有几个字段最终的值会与发送内容不同（见 references/level-schema.md 中的注意事项）。向用户报告任何差异。

8. 构建控制面板链接。 从响应正文中读取 id、applicantType 和 clientId，并按以下格式生成：

   https://cockpit.sumsub.com/checkus/sdkIntegrations/levels/<applicantType>Level/<id>?clientId=<clientId>&sbx=true
   

   <applicantType>Level 片段在 applicantType: individual 时确切为 individualLevel（已确认），在 applicantType: company 时为 companyLevel（类比推测——作为最佳猜测提供；如果返回 404，请标明）。sbx=true 查询参数指向 Sandbox 工作区——这是所有技能共用的标准 Sandbox 链接参数。

9. 报告——以便于理解的名称开头：

   • name、applicantType，以及已创建的 docSet 有序列表。
   • 控制面板链接，使用可点击的 Markdown 链接。
   • 最后一行：Level ID (for SDK access tokens / future PATCH): <id>。

   原样呈现 4xx 错误——它们通常指向缺少 questionnaireDefId 或未知的枚举值。

租户权限

许多级别设置受租户权限（allowedChecks）限制。启用功能前，请确认 sumsub-check-permissions（在步骤 0 中获取）返回的 allowedChecks 映射中包含所需的 BackgroundCheckTarget 键。

DocSet 类型 → 所需权限（或 — 满足任意一项即可）：

DocSet 类型	所需权限（满足任意一项即可）
QUESTIONNAIRE / QUESTIONNAIRE2-4	QUESTIONNAIRE
COMPANY / COMPANY_DATA	COMPANY | KYB_FULL | KYB_AUTO_AML_AND_REGISTRY | KYB_AUTO_AML_ONLY
SOLANA_ATTESTATION / LINEA_ATTESTATION	PAYMENT_METHOD_CRYPTO
PAYMENT_METHODS	PAYMENT_SOURCE | PAYMENT_METHOD | PAYMENT_METHOD_CRYPTO | KYT_UNHOSTED_WALLET_VERIFICATION
INVESTABILITY	PROOF_OF_FUNDS
PROOF_OF_RESIDENCE / PROOF_OF_RESIDENCE2	POA | ADVANCED_POA_TYPE_DETECTION（即使 API 实际允许，allowedChecks 中也经常缺少这些键——继续操作并向用户发出一行警告；见下文）
E_KYC	E_KYC_TARGET
E_SIGN	E_SIGN_TARGET
TR_RECIPIENT_INFORMATION	TRAVEL_RULE
DEVICE_CHECK	DEVICE_INTELLIGENCE

此表中未列出的类型（IDENTITY、SELFIE、APPLICANT_DATA、EMAIL_VERIFICATION、PHONE_VERIFICATION 等）对所有租户均可用——无需权限。

AML / 监控名单筛查 → WATCHLISTS。 这不是 DocSet，而是适用于整个级别的行为。若 allowedChecks 中包含 WATCHLISTS，每个级别默认启用 AML/PEP/制裁筛查（可在每个级别通过 disableWatchlists: true 将其关闭）。若缺少 WATCHLISTS，则整个租户的筛查均已关闭，且无法通过任何级别设置启用——需要 AML 筛查的策略应视为因缺少权限而受阻（联系 CSM），与上述 DocSet 权限限制相同。

如果请求的功能需要租户没有的权限，请立即停止。 不要构建或 POST 级别。告知用户缺少哪项权限、该功能在其账户上不可用，并说明他们需要联系 CSM 或 Sumsub 支持以启用该功能。只有在用户确认已添加该权限，或明确决定放弃该功能后，才继续操作。

例外 — POA。 即使某些租户的 API 实际接受 PROOF_OF_RESIDENCE 级别，POA / ADVANCED_POA_TYPE_DETECTION 键也经常不会出现在 allowedChecks 中（该权限似乎是基础权限或由其他键覆盖；某些租户使用的文档映射已过时）。若仅缺少 POA，继续操作，并向用户发出一行警告，以便他们在之后需要支持时了解情况。不要暂停并等待明确确认——如果租户确实没有相应权限，Sumsub 会自行拒绝写入，且该 4xx 错误比提前中止更有参考价值。如果返回了任何与权限相关的错误，请原样显示。

安全

创建级别会向共享工作区写入数据。务必：

• 在首次 POST 前向用户展示解析后的载荷（上文步骤 4）。
• 每次 POST 成功后，GET 回该实体并与发送内容进行比较——静默覆盖很常见。
• 如果 PoA 预设或问卷已在本次会话中成功创建，不要再次 POST 依赖项——复用返回的 id。
• 除非用户明确指出，否则不要删除或修改本次会话中由你以外的人创建的级别。

面向用户的消息中使用名称，而非 ID

这适用于你向用户发送的关于此级别的每一条消息，不仅限于最终报告：

• **POST 前摘要：**列出将附加哪些问卷和 POA 预设时，请使用各自的 name / title（例如“POA 预设 «POA — 60 days»”“问卷 «Applicant basics»”）。请勿在文字中粘贴原始 id（"6a16bfd4ded0fe13aa48165d"）——用户无法读懂它，也无法据此判断你是否选对了实体。
• **最终报告：**结尾仍须单独一行写上 Level ID (for SDK access tokens / future PATCH): <id>——这是唯一适合显示原始 ID 的地方，因为用户需要复制它以便进行下一次 API 调用。
• **诊断消息：**如果 4xx 响应中引用了依赖项 ID（例如找不到 POA 预设），请在向用户显示前将其转换为名称。

如果你还不知道某个实体的名称（例如，用户提供的 ID 来自本次会话之外），请先 GET 获取该实体，然后显示其名称；不要退而使用 ID。

紧凑规格格式

通过标准输入接受 JSON 或 YAML。构建器会为每种文档集类型填入合理的默认值（参见 references/level-schema.md）。

{
  "name": "Basic KYC",
  "applicantType": "individual",
  "type": "standalone",
  "docSets": [
    {"type": "IDENTITY", "docTypes": ["PASSPORT","ID_CARD","DRIVERS"]},
    {"type": "SELFIE", "videoRequired": "passiveLiveness"},
    {"type": "PROOF_OF_RESIDENCE", "docTypes": ["UTILITY_BILL"]},
    {"type": "QUESTIONNAIRE", "questionnaireDefId": "source-of-funds"}
  ]
}

**新级别必须使用 WebSDK 2.0（websdkNext: true）。**创建时，构建器会自动设置 websdkNext: true——无需在规格中填写；只需确保绝不设置 websdkNext: false（这会发布已弃用的 WebSDK 1.0 级别）。更新现有级别（规格中包含 id）时，构建器会保持 websdkNext 不变，你也应如此：升级线上级别的 SDK 会导致重大的客户端迁移，因此绝不要将其作为无关 PATCH 的副作用来切换——只有用户明确要求时才更改。

支持的 docSets[].type 值

APPLICANT_DATA、EMAIL_VERIFICATION、PHONE_VERIFICATION、IDENTITY、IDENTITY2/3/4、SELFIE、SELFIE2、PROOF_OF_RESIDENCE、PROOF_OF_RESIDENCE2、PROOF_OF_PAYMENT、PAYMENT_METHODS、INVESTABILITY、COMPANY、COMPANY_DATA、COMPANY_DOCUMENTS、COMPANY_BENEFICIARIES、ACCREDITED_INVESTOR、E_SIGN、QUESTIONNAIRE/2/3/4、E_KYC、OTHER_DOCS、TR_RECIPIENT_INFORMATION、DEVICE_CHECK。

按类型提供的简洁快捷配置

type	快捷键	构建器展开为
IDENTITY*	docTypes；videoRequired（disabled / docapture）；captureMode 和 uploaderMode（仅在 docapture 时发送）；nfcVerificationSettings: {mode}	docSet 上的扁平字段——仅包含你设置的字段。请参阅下文的Dashboard ↔ API 映射。
SELFIE*	videoRequired（默认为 passiveLiveness；完整取值：disabled / enabled / photoRequired / passiveLiveness / staticLiveness），docTypes（默认为 ["SELFIE"]）；selfieProcessingSettings: {skipLivenessCheck, skipFaceMatchCheck}（用于支付方式验证——见下文）	仅含 videoRequired［+ selfieProcessingSettings］的 docSet
PROOF_OF_RESIDENCE*	docTypes（默认为 ["UTILITY_BILL"]）；poaPresetId（或 poaStepSettingsId），用于按 id 附加 POA 预设	docSet + poaStepSettingsId
QUESTIONNAIRE*	questionnaireDefId（或别名 questionnaireId）— 必填	仅含基本字段的 docSet
APPLICANT_DATA	fields——字符串数组，或 {name, required, prefill, immutableIfPresent}	带默认值的 fields[]
PAYMENT_METHODS	typeSettings（对象——键：bankCard、bankAccount、cryptoWallet、eWallet——请参阅下文的支付方式验证）；skipOwnershipCheck（布尔值，默认为 false）；skipRiskScoreCheck（布尔值）；walletScreeningProvider（枚举——见架构）	带经验证结构的 paymentSourceSettings；始终生成 types: ["PAYMENT_SOURCE"]
EMAIL_VERIFICATION / PHONE_VERIFICATION	—	仅含基本字段的 docSet
COMPANY	steps——{name, minDocsCnt?, idDocTypes?, idDocSubTypes?, fields?, applicantLevelName?} 数组	完整的 KYB 步骤结构
E_SIGN	esignSettings（透传）	原样传递

docSet 中的未知键会逐字传递给 API，因此需要使用不常见字段时，很容易通过备用方式实现。

IDENTITY 步骤的 Dashboard ↔ API 映射

以下是 Sumsub Dashboard 侧边栏中的原文标签，以及要写入的 API 值。将用户的描述与标签匹配，然后使用对应的值。

Dashboard 控件	标签（用户可见）	API 值	Spec 键
Capture method	文件上传	disabled	videoRequired
Capture method	实时采集	docapture	videoRequired
Capture mode¹	手动采集和自动采集同时生效	manualAndAuto	captureMode
Capture mode¹	仅手动采集生效	manualOnly	captureMode
Capture mode¹	无缝实时采集	seamless	captureMode
Fallback to file upload¹	始终可用	always	uploaderMode
Fallback to file upload¹	仅在摄像头采集失败时可用	fallback	uploaderMode
Fallback to file upload¹	不可用	never	uploaderMode
NFC verification²	已禁用	disabled	nfcVerificationSettings.mode
NFC verification²	可选	optional	nfcVerificationSettings.mode
NFC verification²	必需	required	nfcVerificationSettings.mode

¹ 仅在 videoRequired: docapture 时有意义。否则会从负载中静默移除（与 Dashboard 自身的行为一致——单选按钮切换到 File upload 时，它会删除这两个键）。 ² required 会自动拒绝 Web SDK 申请人；仅适用于 Mobile SDK。

构建器输出的默认值（Dashboard 要正确渲染所必需——控件绑定到实际存储的值，而非隐式 UI 默认值；空字段会显示为“Select”占位符，而不是默认选项）：

• videoRequired: docapture → captureMode: manualAndAuto、uploaderMode: always（除非调用方覆盖）。
• 除非调用方覆盖，否则 IDENTITY 始终会得到 nfcVerificationSettings: {mode: disabled}。

这些值与用户首次切换到 Live capture 时，Dashboard 自身的 Vue watcher 写入的值一致。PATCH 注意事项： requiredIdDocs.docSets 会被整体替换（仅合并顶层 Level 字段）——PATCH spec 中的每个 docSet 都必须携带完整的预期状态，因为省略的子字段会被清除。请先 GET 该 level，并复制想要保留的值。

AML / watchlist 筛查：两个独立的开关

1. 租户开关——WATCHLISTS entitlement（在步骤 0 中检查）。如果 WATCHLISTS 位于 allowedChecks 中，则 AML 筛查可用，并且默认会在每个 level 上运行。如果没有，则整个租户都关闭了筛查，且没有任何 level 设置能将其开启——应将其标示为缺少 entitlement（联系 CSM），不要误称 level 设置可以启用筛查。
2. Level 开关——disableWatchlists（仅当租户拥有 WATCHLISTS 时才有影响）。要对此 level 关闭筛查，请发送顶层字段 "disableWatchlists": true；省略该字段（或设为 false）则保持开启。watchListCheckSettings.amlCaseType 仅用于选择 provider（受租户开关控制），useCustomWatchListCheckSettings 仅用于选择自定义或继承配置——二者都不是开关。

因此，对于 要求 进行 AML 筛查的策略：确认步骤 0 中有 WATCHLISTS，然后不向 level 添加任何内容，并 GET 回来确认 disableWatchlists 不是 true。对于必须跳过 AML 的 level，请设置 disableWatchlists: true。详情：references/level-schema.md。

支付方式验证（步骤或操作）

支付方式验证——用于验证银行卡、银行账户、加密货币钱包或电子钱包的 PAYMENT_METHODS docSet——有两种模式：

• 作为步骤添加到常规验证级别中：在 IDENTITY / SELFIE / PROOF_OF_RESIDENCE / 等 docSet 旁添加 PAYMENT_METHODS。该级别仍是常规的 standalone 级别，不设置 actionType。当支付验证是更广泛的用户引导流程的一部分时，使用此模式。
• 作为操作添加到 actions 类型级别中：设置 type: "actions" 和 actionType: "paymentMethod"。当需要独立、可重新运行且与用户引导流程解耦的支付方式检查时，使用此模式。

根据用户的描述选择模式——“将银行卡/钱包验证添加到我的 KYC 级别”→ 步骤；“创建独立的支付方式检查 / 操作”→ 操作。

步骤模式——位于标准级别中（身份验证与支付验证共存）：

{
  "name": "KYC + payment method",
  "type": "standalone",
  "applicantType": "individual",
  "docSets": [
    {"type": "IDENTITY"},
    {"type": "SELFIE", "videoRequired": "passiveLiveness"},
    {"type": "PAYMENT_METHODS",
     "typeSettings": {"bankCard": {"allowed": true, "countImages": "one"}}}
  ]
}

操作模式——位于 actions 级别中：

{
  "name": "Payment method check",
  "type": "actions",
  "actionType": "paymentMethod",
  "websdkNext": true,
  "docSets": [
    {"type": "PAYMENT_METHODS", "skipOwnershipCheck": false,
     "typeSettings": {"bankCard": {"allowed": true, "countImages": "one"}}}
  ]
}

构建器强制执行的约束：

• actionType: "paymentMethod" 要求 type: "actions"，且该级别必须包含 PAYMENT_METHODS docSet。
• 不能同时设置 skipOwnershipCheck: true 和 skipRiskScoreCheck: true。
• walletScreeningProvider 应放在 paymentSourceSettings 级别，而不是放在 typeSettings.cryptoWallet 内（构建器会将其放置到正确位置）。
• bankAccount 需要明确的验证方式。 与 bankCard 不同，仅将银行账户设为 allowed: true 会被 API 拒绝——必须至少启用 allowBankStatementUpload（上传账单，无需额外权限）或 allowExternalSourcesCheck（外部数据源检查，需要 E_KYC 权限）。询问用户想要哪种方式；不要提供不指定方式的“标准”银行账户选项。

PAYMENT_METHODS docSet（两种模式均适用）： 构建器始终会生成 types: ["PAYMENT_SOURCE"]，以及一个根据精简配置组装的 paymentSourceSettings 对象——API 会拒绝缺少 paymentSourceSettings 的 docSet，因此构建器不会省略它。

各支付来源类型的 typeSettings：

键	字段
bankCard	allowed（bool）；countImages（"one" / "two" / "some"）；extractIban（bool）；extractNationalBankAccountNumbers（bool）；requireBankAccountNumber（bool）
bankAccount	allowed（bool）；allowBankStatementUpload（bool）；allowExternalSourcesCheck（bool — 需要 E_KYC_TARGET 权限）。设为 allowed 时，这两种方式中至少有一种必须为 true——见上文约束。
cryptoWallet	allowed（bool）；satoshiTestAllowed（bool）；unhostedWalletFormType（"DEFAULT" / "SIMPLE" / "KAZ" / "TUR" / "SGP" / "POL" / "ITA"）
eWallet	allowed（bool）

walletScreeningProvider 枚举： crystal / merkle / trmLabs / chainalysis / elliptic / cyvers

权限： 需要 PAYMENT_SOURCE 或 KYT_UNHOSTED_WALLET_VERIFICATION（见 租户权限）。

控制面板链接： 两种模式都位于 sdkIntegrations/levels/individualLevel/<id> 下——这是标准 standalone 级别的 URL 模式。

完整的操作模式配置请参见 examples/payment-methods.json。

数据库／非文档验证（KYC）

范围：仅限 KYC（个人）。 此路径不涵盖公司／KYB 数据库检查。

当请求表示需要将申请人数据与数据库／注册登记库核对，而非（或除）核对文档时，相关信号包括：“non-doc”、“eKYC”、“no document”、“against a database/registry”、“validate the ID / SSN / DNI number”。请在构建载荷之前，通过 sumsub-check-databases 确定并配置数据源：

1. 运行 sumsub-check-databases <country>。当 status == "ENABLED" 时，数据源可用；SANDBOX_ONLY 可在沙盒中运行，但无法在生产环境运行（如果用户打算上线，请在构建级别之前说明这一点）；DISABLED 则完全不可用。如果用户需要的数据源不可用，请遵循该技能的替代方案和启用指南（不要默默省略它——请引导用户前往 Databases → Available products，大多数数据源都可自行启用）。
2. 每个数据源的 validationReady／stepsReady 决定其配置位置——这两个信号相互独立，请同时检查：

信号	docSet	备注
validationReady: true	保留文档 docSet（例如 IDENTITY，保留 types）	数据源会将上传文档中的数据与数据库交叉核验。将其配置在级别的顶层 checkSourceSettings 中（与 requiredIdDocs 同级，不要嵌套在其中或 docSet 中）。
stepsReady 包含一个单独出现的类型（例如 E_KYC）	使用该类型的独立 docSet，不带 types 字段	仅数据库检查，不上传文档。E_KYC 需要 E_KYC_TARGET。将 checkSourceSettings 嵌套在此 docSet 中。
stepsReady 包含一个与已要求的文档步骤并列的类型（例如 IDENTITY）	保留该文档 docSet 的 types	申请人可在同一步骤中选择上传文档或进行数据库检查。也需要 E_KYC_TARGET。将 checkSourceSettings 嵌套在同一个 docSet 中，不要放在顶层。

如果某个数据源的 stepsReady 列出了多个步骤类型，这表示有多个可选配置位置，并不意味着必须全部使用——请选择符合用户意图的位置。

3. 通过 checkSourceSettings.countrySettings[] 配置所选数据源——可以放在级别的顶层（与 requiredIdDocs 同级的 checkSourceSettings 键，用于 validationReady 配置），也可以嵌套在相关 docSet 中（用于 stepsReady 配置）：

"checkSourceSettings": {
  "countrySettings": [
    {
      "country": "ARG",
      "checkType": "E_KYC_CHECK",
      "groupType": "INPUT_COUNTRY",
      "executionConfigurations": [
        {"sourceId": "arg_gov_dni", "fallbackReasons": []}
      ]
    }
  ]
}

• country、checkType 和 sourceId 直接取自 check-databases 响应。
• groupType：使用 INPUT_COUNTRY（申请人的国家／地区）——这是默认值。TARGET_COUNTRY 仅用于少见的跨境数据源（例如签证检查）。
• executionConfigurations 有顺序——列出多个 sourceId，即可依次回退。fallbackReasons（例如 NAME_MISMATCH、DATA_NOT_FOUND）会触发回退至下一个数据源；[] = 不回退。

有关三种配置位置的完整示例，请参阅 examples/identity-selfie-with-database-validation.json（顶层，validationReady）、examples/identity-with-non-doc-selfie.json（嵌套在 IDENTITY 中）和 examples/non-doc.json（独立的 E_KYC）。

字段含义、枚举值以及不可用数据源的处理方式，请参阅 sumsub-check-databases 和其架构参考。

与其他 Sumsub-* 技能链式配合

此技能的 QUESTIONNAIRE 和 PROOF_OF_RESIDENCE 文档集可以接收由同级技能生成的 ID，因此很适合采用从零构建所有内容的三步流程：

先运行……	将返回的 id 作为……传入
sumsub-create-questionnaire	QUESTIONNAIRE 文档集上的 docSets[].questionnaireDefId
sumsub-create-poa-preset	PROOF_OF_RESIDENCE 文档集上的 docSets[].poaPresetId

参见 examples/with-presets.json，了解同时引用两者的端到端级别示例。

对于数据库／非文档验证，请运行 sumsub-check-databases 来解析数据源，并通过 checkSourceSettings 附加这些数据源——请参见上文的数据库／非文档验证。

输出

成功时，先提供便于阅读的信息：

• name、applicantType、docSets[].idDocSetType 的有序列表。
• 控制面板链接：https://cockpit.sumsub.com/checkus/sdkIntegrations/levels/<applicantType>Level/<id>?clientId=<clientId>&sbx=true。以可点击的 Markdown 链接形式呈现。<applicantType>Level 部分对于个人为 individualLevel（已确认），对于公司为 companyLevel（根据模式推定）。所有三个字段（id、applicantType、clientId）均来自 POST 响应正文；sbx=true 指向 Sandbox 工作区。
• 最后单独一行输出：Level ID (for SDK access tokens / future PATCH): <id>。

失败时：HTTP 状态码，以及 Sumsub 错误信封中的 description／errorName。

示例

• examples/identity-selfie.json — 最常见的模式。
• examples/identity-live-capture.json — 仅包含 IDENTITY，并启用 Live capture、所有 docapture 子选项以及 NFC。
• examples/questionnaire-only.json — 纯数据收集级别（类似此代码库中的 SOF 级别）。
• examples/full-kyc.json — APPLICANT_DATA + IDENTITY + SELFIE + PROOF_OF_RESIDENCE + QUESTIONNAIRE。
• examples/kyb-company.json — 包含公司、UBO 和代表步骤的 KYB 级别。
• examples/with-presets.json — 引用由同级技能返回的问卷（questionnaireDefId）和 POA 预设（poaPresetId）。
• examples/payment-methods.json — 包含银行卡、银行账户、加密货币钱包和电子钱包的支付方式操作级别。
• examples/identity-selfie-with-database-validation.json — 数据库验证（validationReady）：保留文档上传，由数据源通过顶层 checkSourceSettings 对其进行交叉核验。
• examples/identity-with-non-doc-selfie.json — 在现有步骤中进行非文档验证（stepsReady）：将 checkSourceSettings 嵌套在 IDENTITY 中，申请人可以上传文档或使用数据库核验。
• examples/non-doc.json — 独立的非文档验证（stepsReady）：专用的 E_KYC docSet，无需上传文档。

另请参阅

• references/level-schema.md — 完整的 ApplicantLevel 架构、所有枚举值及注意事项。