API密钥

API密钥并非持有登录凭证的成员，它拥有一套更简单的独立权限模型：

两种模型刻意保持独立。成员拥有角色、配置文件和账户级精细权限，因为人员往往承担多样化的职责。密钥采用扁平的权限范围加账户模型，因为自动化操作应当范围精简、规则统一，便于一目了然地审计。

每个API密钥包含两项配置：权限（可执行的操作）与账户（作用范围）。

权限

账户映射

每个密钥在创建时关联一个或多个账户，后续可随时编辑。密钥的权限统一适用于所有已选账户：

• 拥有“查询资金”以及“创建及修改订单”权限的密钥，可在两个已选账户上读取余额并进行交易，无法执行其他操作。
• 密钥不支持按账户设置差异化权限。若自动化程序需要在某一账户进行交易、仅读取另一账户，建议使用两个密钥分别管理。如此一来，每个密钥的影响范围一目了然。

FIX连接

拥有订单权限的密钥，除REST和WebSocket API外，还支持通过FIX协议进行现货交易。FIX会话继承所关联密钥的权限和账户映射：仅在密钥已选账户范围内交易，且不超出密钥权限。使用FIX订单流的机构通常为每个会话单独配置一个密钥，并限定在对应交易台的账户范围内。

安全设置

组织治理既适用于密钥的操作行为，也适用于密钥的管理方式。

密钥的操作行为

成员适用的两类规则同样适用于密钥：

• 直接操作立即执行。交易、理财、持有币种查询、分类账查询及数据导出均在密钥权限和账户范围内即时完成。
• 受治理操作将创建请求。由密钥发起的提款或地址变更请求与成员发起的请求进入同一处理流程：由工作流策略决定是立即完成，还是进入审批队列等待人工审核。

密钥只能发起受治理请求。密钥不具备审批权限；职责分离要求每笔审批均由人工成员完成，脚本无法替代这一判断。当提款请求策略要求两人审批时，由密钥发起的提款须等待两位成员批准，与成员发起的请求完全一致。

请在设计自动化流程时考虑这一异步特性：API调用成功仅表示请求已创建，并不代表资金已划转。请持续跟踪请求直至完成，并注意当前限制：待处理请求不会预留资金，若审核期间余额发生变动，已审批的请求将失败，届时需重新提交。请参阅审批前保持资金充足。

密钥也无法访问任何管理工作流。团队访问权限、API密钥、账户、地址（超出发起地址请求的范围）及策略的管理，均为成员专属操作。

密钥的管理方式

API密钥的创建、编辑与撤销属于受治理操作，须通过专用的“管理API密钥”工作流执行，与“管理团队与访问权限”工作流相互独立。这一分离体现在两个方面：

• 管理员职责独立。可授权运维工程师管理密钥，而不赋予其变更成员访问权限的能力，反之亦然。
• 策略各自独立。密钥管理可设置独立的审批要求。许多组织要求对密钥的创建或修改进行独立审批：新凭据意味着新的账户访问入口；与此同时，撤销流程仍需保持高效快捷。

1. 前往API密钥，选择创建密钥。
2. 请按密钥的用途命名，注明其服务的系统及功能，以便在审查和安全事件中一目了然。
3. 选择密钥的权限。
4. 选择密钥所操作的账户。所选权限将统一应用于所有账户。
5. 配置安全设置：到期日期、IP限制、随机数窗口。
6. 请审核并确认。若管理API密钥策略要求审批，请求须在获得所需审批后方可签发密钥。

编辑密钥的权限或账户，以及撤销密钥，均须遵循相同的治理流程。

此次调用已创建提款请求，目前正由提款请求策略保留等待审批。请前往“请求”页面查看，该请求将以密钥为发起方显示，等待成员完成所需审批。这正是治理模型的预期运作方式：自动化发起请求，人工进行审批。

若请求已获批但资金仍未划转，请检查完成时源账户持有币种是否充足。待处理请求不会预留资金，审批期间若账户发生变动，已批准的请求可能因此失败。请在持有币种恢复充足后重新提交。

出现问题的账户不在该密钥的账户映射范围内。密钥仅对其已选定的账户生效。请编辑密钥以添加该账户。请注意，密钥的完整权限集将统一应用于该账户，密钥不支持按账户差异化配置权限。若权限范围过宽，请创建第二个密钥，专门绑定至该新账户。

单个密钥无法针对不同账户设置不同权限。请创建两个密钥：一个交易密钥映射至账户A，一个只读密钥映射至账户B。权限范围更窄的密钥也更易于审计，撤销时风险更低。

管理API密钥工作流可能需要审批，相关请求仍在待处理中。密钥及其私密信息仅在收集到所需审批后才会发放并显示。请在“请求”页面查看该请求的状态。

不可以。审批始终需要由真实成员执行。这是系统规则，而非可配置策略。正是这一机制，确保了自动化流程发起资金操作时，多方审批具有实质意义。