组织、应用与环境

组织承载你的团队和账单；应用承载工作流和 API 密钥，且每个应用要么是 live 要么是 sandbox。理清这个结构能避免大多数令人困惑的行为。

Didit 支持团队撰写 · 更新于 2026年9月15日

#两个层级

组织是你的账户。它拥有：

• 你的团队及其角色
• 你的账单余额和发票
• 你的审计日志
• 你所有的应用

应用是组织内的一个工作空间。它拥有：

• 自己的工作流
• 自己的 API 密钥
• 自己的 webhook 目标地址
• 自己的数据保留策略
• 一个模式：live 或 sandbox

在控制台顶部的下拉菜单中切换应用。

#为什么这比看上去更重要

几乎所有"我改了但什么都没发生"的报告，都可以归结为这个结构：

• 你在应用 A 中编辑了一个工作流，而你的会话实际运行在应用 B 下。
• 你在一个应用上添加了 webhook 目标地址，却期望收到另一个应用的事件。
• 你用某个应用的密钥去调用，而你要访问的资源属于另一个应用，结果对一个明明存在的东西收到 404 或 403。

在排查其他问题之前，先确认应用是否正确。参见API 错误及其含义。

#Live 和 sandbox 是两个独立的应用

live 应用内部并没有一个测试模式开关。模式是按应用选择的，因此测试意味着创建第二个 sandbox 模式的应用，并使用它的密钥。

这种隔离正是关键所在：测试流量和生产数据永远不会混在一起，sandbox 密钥也不可能意外消耗真实额度。参见在 sandbox 中测试。

#应该有多少个应用？

至少要有一个 live 和一个 sandbox。除此之外，按任何需要独立配置或独立隔离的维度进行拆分：

• 按产品拆分，当不同产品需要不同的工作流和不同的 webhook 端点时。
• 按环境拆分，如果你运行多个预生产环境。
• 按品牌拆分，如果你以多个不同品牌样式提供核验服务。
• 按保留策略拆分，因为保留策略是按应用配置的。

不会按应用拆分的是你的余额，它是组织级别的。每个应用都从同一份额度中扣款。

#创建更多应用

额外的应用可以在控制台中创建。如果没有这个选项，或者你需要通过 API 而非控制台来创建应用，这属于账户级别的权限问题，值得向支持团队询问，而不是自行想办法绕过 - 尤其是创建第二个 live 应用时，答案可能与你的套餐有关。

#多个组织

一个人的邮箱一次只能属于一个组织，并且无法在您的组织下创建子组织或子账户。如果您服务多家自己的客户，受支持的结构是在您唯一的组织内为每个客户建一个应用：每个应用有自己的工作流、品牌、API密钥、结果和用量报告，彼此完全隔离，而计费留在组织层面。

#转售Didit

如果您想把Didit打包进自己的产品并向客户收费，这就是经销商模式。支持团队向每位询问者给出的条款如下：

• 预付额度。 最低首次购买5,000美元，预付，一年期协议。额度永不过期，位于您的组织层面，由您接入的所有终端客户共同消耗，并附带随金额递增的批量折扣。
• 控制面板由您构建。 您把Didit的API集成到自己的前端，客户在那里管理他们的工作流、品牌和角色。Didit不提供Business Console的白标副本；终端用户看到的验证页面可以带您的品牌（参阅白标），控制台不行。
• 利润归您。 您决定客户支付的价格。Didit按已完成的功能、以协议期内固定的单价向您收费。
• 这不是本地合作伙伴计划。 Didit直接面向客户提供演示、开通和支持，不寻找分销或实施合作伙伴。

如果您不想承担转售，可以改用推荐选项：在Business Console侧边栏打开推荐，接受计划条款并分享您的链接。被推荐组织自首次充值起36个月内的每笔现金充值，您可获得10%佣金，可作为Didit额度使用，或在成熟期后申请银行转账，无需承担交付或支持义务。在决定任一方案之前，您都可以在免费额度内构建和测试集成。

#删除应用

删除一个应用会移除它的工作流和配置。它的核验数据遵循该数据自身的保留策略和删除规则，而不是随应用的生命周期走 - 因此如果你的目标是清除客户数据，请显式删除数据，而不要假定删除应用就能做到这一点。参见删除会话与个人数据。

#一切都可追溯

每一次 API 调用都会在审计日志中记录它所属的应用，保留 365 天。正是这一点，让多应用结构变得可审计，而不仅仅是整洁。参见使用审计日志。