从测试版迁移

本文适用于在 Beta 访问模式下创建的组织,在该模式中,管理员单独授予每个成员权限。现在,访问权限基于 Workflow ProfilesAccount Roles 构建,Kraken 将为您转换您的组织。

在转换之前,有两件事需要您注意:

  • 如果您使用 API 密钥,您的集成必须首先更新。请求选择账户的方式已更改,成功的提款调用不再意味着资金已转移。请参阅下方的“更新您的 API 集成”。
  • 我们会要求您确认是否准备就绪。在您接受更改之前,您的组织不会被转换。

转换不会移除任何访问权限。成员持有的所有权限都将延续。

您现有的 API 密钥不会被撤销或重新签发。它们的凭据、权限和账户映射都将延续。变化在于您的代码如何处理请求和读取响应。

在每个请求中选择一个账户

组织 API 密钥涵盖一个或多个账户,并且没有默认设置,因此每个私有请求都必须指明它适用于哪个账户。将 account_id 作为 URL 上的查询参数传递,而不是在请求正文中传递:

bash

Bash

POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYH

这适用于交易、余额和分类账查询、订单和交易历史记录、导出以及资金移动等。

警告:

阅读新的提款响应

WithdrawFunds 会返回 approval_request_id 以及 refid

bash

Bash

{
  "error": [],
  "result": {
    "refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
    "approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
  }
}
  • refid 不再表示提款已完成。请求提交时,金额会锁定在来源账户中,并且仅在请求获得批准后才会结算。
  • approval_request_id 是提款等待批准的句柄。请将其存储到您自己的记录中。
  • 等待批准的提款不会出现在 WithdrawStatus 中。被拒绝或过期的请求根本不会创建提款记录,因此 WithdrawStatus 中没有记录并不意味着未提交提款。

refid 视为完成证明的自动化系统会将提款报告为已结算,而实际上它们仍在审批队列中。有关完整模型,请参阅API 密钥

您的组织在转换后将获得两套标准构建模块。

Workflow Profiles

Workflow Profile 规定了成员可以在每个受管工作流上执行的操作。每个成员只持有一个。

配置文件

包含内容

管理员

每个工作流的各个级别,包括执行

发起人

查看和发起每个工作流。无法批准

审批人

查看和批准每个工作流。无法发起

审计员

查看每个工作流。无法操作

资金经理

查看、发起和批准提款请求和转账请求。查看和发起管理地址

Account Roles

Account Role 规定了成员可以在您的账户上执行的操作。标准角色涵盖所有当前和未来的账户,因此拥有 Trade all 权限的成员可以在您明天创建的账户上进行交易。

角色

它在每个账户上授予什么权限

读取所有

读取

交易所有

交易

所有资金

转账、提现、收益分配、收益解除分配

完全访问

所有账户权限

标准档案和角色与产品同步:当添加新工作流程时,拥有相应档案或角色的成员将自动获得适当的级别。有关完整模型,请参阅角色、档案和权限

如果成员的权限不符合任何标准档案,他们将被分配到与其原有权限完全相同的角色。具有相同权限的成员共享一个角色,因此您的组织的角色数量将远少于成员数量。

这些角色以您在成员旁边写下的标签命名,因此标记为“Trader”的成员将获得名为trader的角色。没有标签的成员将获得migrated-role角色。每个角色都带有已迁移徽章,这意味着该名称是自动生成的,您可以更改。

提示:

在转换后,将这些角色重命名以匹配您实际称呼这些人的名称是首要任务。编辑角色会清除已迁移徽章。

为什么您的“管理员”成员不在管理员档案中

Beta 版的“管理员”标签允许某人查看、发起和批准请求,但不能在没有第二次批准的情况下完成自己的请求。管理员档案确实包含此能力,即“执行”级别。

成员不会自动获得此权限,而是将具有旧标签的成员分配到名为beta-admin的角色,该角色拥有他们已有的确切权限。您可以随时将他们分配到管理员档案中。

注意:

beta-admin是您自己的角色之一,因此持有此角色的成员不会像标准档案那样自动获得新工作流程。这是在转换后尽快审查这些角色的另一个原因。

所有者被分配到管理员档案,保留其所有原有权限,并自动获得新工作流程。所有者还拥有“读取所有”权限,此权限不可移除。

如果您曾有意减少所有者的权限,该决定将得以保留:所有者将像其他成员一样转换为持有其实际权限的角色。

  • 每位成员持有的所有权限都将延续。
  • API 密钥凭据、权限和账户映射都将保留。
  • 余额、账户和账户所有权不受影响。
  • 已处理的审批请求将继续进行,您的政策、审批阈值和“始终要求审批”设置保持不变。
  • 身份验证不受影响,没有人需要再次登录或重新受邀。
  • 仅转换属于您组织的账户。组织外部任何账户的权限将保持不变。

故障排除

该请求几乎肯定缺少 account_id。缺少此参数,私有调用将无法解析到密钥的账户之一,并可能返回空结果而非错误。请将 account_id 添加到 URL,并重新检查您的集成所调用的所有端点,而不仅仅是那些明显失败的端点。请参阅API 密钥

该调用创建了一个请求并锁定了源账户中的金额。结算在批准后进行。您可以使用调用返回的 approval_request_id 跟踪请求,或在“请求”页面上查找。请参阅转账和提款

其权限与标准配置文件不匹配的成员,需要一个保留其访问权限的角色,并且仅当两名成员的权限完全相同时,才将其合并到一个角色中。您曾赋予不同标签的成员即使权限匹配,也仍会保持在不同的角色中,因为标签暗示了这种区别是有意的。您可以通过重新分配成员并删除空角色来整合不需要的角色。

管理组织(管理团队访问权限、账户或 API 密钥)的成员将被置于“全部读取”权限下,因为管理账户意味着能够查看账户。如果这超出了您的预期范围,请用限定于特定账户的“账户角色”来替换“全部读取”。

不能。转换是单向的。转换后产生的所有内容都是可编辑的,因此您原有的任何访问安排都可以通过配置文件和角色重建。

需要更多帮助?