API 访问、范围和开发人员权限政策
X2 如何按服务、目的和权限授予模块化 API 访问权限。
一、原理
X2 按目的、服务和许可提供对技术的访问，而不是通过无限制地访问 X2 平台。
2. 基于服务的访问
支持的 API 域可能包括目录、版权和出版、分发、分析、受众、社交和 UGC 货币化、版税和报告、人工智能验证、专业验证和其他授权服务。访问一个域并不意味着访问另一个域。
3. 基于范围的授权
凭证可能仅限于读取、写入或敏感操作，例如catalog.read、catalog.write、rights.read、rights.claims.submit、distribution.submit、analytics.read、royalties.read 或ai.verify。最终的技术范围名称在 API 规范中定义。
4. 用户、工作空间和组织授权
应用程序只能访问属于授权用户、组织或已被授予明确许可的其他实体的资源。无限制的跨客户访问不属于普通 API 授权的一部分。
5. 申请注册
在授予访问权限之前，X2 可能需要开发人员或公司身份、应用程序名称、预期目的、重定向 URL、请求的范围、预期流量、安全信息、数据保留实践和联系方式。
6. 审批级别
X2 可以根据风险、功能和合同要求区分标准访问、经过验证的开发人员访问、受限访问以及企业或合作伙伴访问。
7. 敏感范围
权利转让、所有权变更、受益人变更、支付指令、KYC 或身份数据、强制执行行动、批量索赔和其他敏感功能可能需要手动批准、更强的验证或单独协议。
8. 财务许可
阅读特许权使用费报告的权限不会自动授权受益人变更、银行账户变更或付款启动。
9. 权限
读取权利数据的许可并不自动授权权利转让、索赔或所有权变更。
10.OAuth 同意
代表用户的应用程序应该请求明确的范围并清楚地呈现这些权限。用户应该能够撤销未来的访问权限。
11.没有通用API密钥
X2 不使用自动授予对每项服务的访问权限的通用凭证。凭证应与所有者、应用程序、范围、环境、限制和状态相关联。
12. 审计追踪
敏感 API 操作可能会记录参与者、应用程序、范围、资源、操作、时间和结果。
13. 沙箱和生产
沙箱和生产访问是分开的。生产访问可能需要额外的验证和批准。
14. 内部服务到服务的访问
同样的最小权限原则也适用于内部 X2 服务。一项服务应该仅接收其功能所需的 API 权限，而不是不受限制的数据库访问。
15. 提供者适配器
外部 DSP、金融提供商、版权组织和其他适配器仅接收特定集成所需的数据访问。
16. 数据导出
授权用户可以导出合格的目录、元数据、权利、报告、注册或其他支持信息，而无需接收不相关的客户数据、专有内部数据集、安全信息或欺诈模型。
17. 费用和暂停
API 访问可以是免费的、基于服务的或基于使用的。 X2 可以暂停滥用的凭证或应用程序，而不必暂停整个客户帐户。