Rivya API 是给开发者使用的接入路径，用来从你自己的产品、脚本或工作流里调用 Rivya 模型能力。
它不是 Rivya Studio 之外的另一套产品。它仍然使用同一个账号边界、同一个积分钱包，以及用户在 Rivya 里看到的公开模型层。区别在于任务从哪里开始：不是人在 Studio 里点击操作，而是你的应用通过 API Key 发起请求。
如果你需要端点和请求字段，请从 Rivya API 总览 和 Rivya API 快速开始 读起。这篇文章只回答产品层问题：API 适合做什么、放在什么位置、什么时候不该一上来就用 API。
先用短句理解
Rivya API v1 让登录账号可以创建 API Key，并从网页界面之外调用 Rivya 的模型能力。
当前 API 覆盖：
通过 API 模型列表发现可调用模型
提交异步图片、视频和音频生成任务
为需要参考素材的模型使用 Files API 上传文件
通过公开任务 ID 查询生成状态
查询账户积分
调用 Chat API，包括可选 SSE streaming
为生成任务完成结果配置签名 Webhook
使用仓库内 TypeScript SDK beta 封装部分调用
公开开发者入口是 Developers。如果你想先看整体能力、API Key 入口和安全调试方式，先从那里开始更顺。
Rivya 为什么需要 API
当人还在选模型、改提示词、看输出、决定下一步时，Studio 更适合。
当这件事已经变成可重复的产品流程或运营流程时，API 更适合。
常见场景包括：
用户在你的产品里提交 brief 后，自动生成图片变体
营销流程根据结构化 campaign 输入生成视觉草稿
内部工具不经过浏览器，直接提交视频或音频任务
支持系统或内容系统想在自己的界面里调用一轮 Chat 模型
后端服务希望任务完成后收到签名回调
这些场景里，Rivya API 的价值是让模型选择、计费和任务状态仍然留在同一个 Rivya 账号体系里，而不是再搭一套分散链路。
API 不替代什么
API 不应该替代所有直接使用 Rivya 的理由。
下面这些情况更适合继续使用 Studio 或公开工作入口：
提示词还在探索
模型选择还不稳定
创作者需要肉眼比较输出
项目依赖保存历史和人工复核
团队还没决定哪种输入和输出值得自动化
工作流清楚到可以自动化时，再用 API。
这个边界很重要。模糊的创意问题通常先留在 Studio。输入和输出都比较稳定的产品流程，才适合搬到 API。
API 的主要组成
可以把 API 理解成 6 个互相连接的部分。
| 模块 | 负责什么 | 继续阅读 |
|---|---|---|
| API Key | 让服务器从你的账号访问 API |
