认证
租户、终端用户和代理模式三种 API 访问方式所用的请求头方案。
凭据类型
| 方案 | 请求头 | 身份等同于 |
|---|---|---|
| 租户 API 密钥 | X-API-Key: tk_…(或 Authorization: Bearer tk_…) | 你的租户 |
| 代理模式终端用户 | X-API-Key: tk_… + X-End-User: <your-user-id> | 由你的后端声明的某位特定终端用户 |
| 平台终端用户 | Authorization: Bearer <jwt> | 通过 /auth/login 或 OAuth 登录的终端用户 |
可选的 X-Space-Id 请求头用于指定某个空间;不传时使用该用户的默认空间。
无论用哪种方案,最终都会解析成一个主体(租户 · 用户 · 空间),数据库会话则按这个身份、通过 Postgres 行级安全策略划定范围——也就是说,隔离是在 API 之下强制执行的,而不是靠应用代码。
我该用哪一种?
- 服务端对服务端集成(由你的产品驱动对话):用代理模式。租户密钥由你的后端持有,每次请求声明终端用户身份——用户永远看不到密钥。
- 你自己的客户端应用,且用户直接登录平台:用终端用户 JWT。
- 管理类自动化(管理文档、智能体、用量):用纯租户密钥调用管理接口。
租户 API 密钥是服务端机密。绝不要把它打包进浏览器代码或移动应用——浏览器场景请用可嵌入挂件,它走的是分享令牌认证。
代理模式示例
curl https://chat.agent4.io/chat \
-H "X-API-Key: tk_live_…" \
-H "X-End-User: crm-user-8841" \
-H "Content-Type: application/json" \
-d '{ "message": "What documents do I need for a refinance?" }'终端用户 ID 可以是你系统里任何稳定的标识符。平台在第一次见到它时创建该用户及其默认空间,并把所有历史、记忆和文档都限定在其范围内。
错误码
| 状态码 | 含义 |
|---|---|
401 | 缺少凭据或凭据无效 |
403 | 身份有效,但无权访问所请求的空间/智能体 |
429 | 每月 Token 配额已耗尽 |