⌘
项目 API Key
为不同项目分配独立访问密钥，便于轮换、停用和权限边界梳理，而不是把上游凭据分散在客户端。
KEY MANAGEMENT →UNIFIED API ACCESS LAYER
为团队打造的
统一 API 接入层
用一个面向项目的访问密钥，规划标准消息接口、用量边界与调用记录，让团队把注意力留给产品本身。
独立服务页面，不代表 Anthropic、Claude 或任何上游模型提供方官方。
POST /v1/messages
$ curl https://BASE_URL/v1/messages \
-H "x-api-key: YOUR_RELAY_KEY" \
-H "content-type: application/json" \
-d '{
"model": "MODEL_ID",
"messages": [ ... ]
}'
200请求已响应429达到速率限制401密钥无效
PRODUCT FOUNDATION
围绕团队调用而设计的
三个基础能力
中转服务应将调用身份、接口兼容性与资源边界集中管理。具体可用模型、限额和服务等级以正式开通方案为准。
⌁
标准消息接口
以统一的 Messages 请求格式组织调用，在应用侧保持清晰、一致的请求与错误处理习惯。
MESSAGES API →◔
用量与限额
按项目建立预算、速率和调用量边界；稳定运行还应配合日志、告警和异常调用的处置流程。
USAGE POLICY →HOW IT WORKS
三步连接模型能力，
把控制权留在你的团队。
你的应用
通过标准 API 发送消息请求，不在前端保存上游服务密钥。
→
Claude API 中转
验证项目密钥，执行配额与速率策略，并保留必要的调用审计信息。
→
上游服务
由服务端安全保存和调用授权后的上游凭据，再将响应返回给应用。
REQUEST EXAMPLE
从一条标准请求开始
以下仅展示接入结构，避免误把页面示例当作可直接访问的生产地址。实际基址、模型标识与权限范围，应在开通后以服务端配置为准。
- POST /v1/messages
- AUTH x-api-key: YOUR_RELAY_KEY
- BODY JSON messages payload
- ERROR 401 / 429 / 5xx 需在应用侧处理
curl https://BASE_URL/v1/messages \ -X POST \ -H "content-type: application/json" \ -H "x-api-key: YOUR_RELAY_KEY" \ -d '{ "model": "MODEL_ID", "max_tokens": 1024, "messages": [{ "role": "user", "content": "你好" }] }'
FAQ
在接入之前，先明确边界
这是 Anthropic 或 Claude 官方服务吗？
不是。本页面仅展示独立 API 中转服务的产品方向，不代表 Anthropic、Claude 或其他模型提供方官方，也不替代其官方文档和账户条款。
上游 API Key 应该如何保存？
上游凭据应仅保存在受控服务端环境中；不要把它放入浏览器、移动端包或交给终端用户。面向用户或项目的应是可撤销的中转访问密钥。
仅有 Organization ID 可以完成接入或付费吗？
不可以把公开标识当作付款或管理授权。真实开通需要经过服务方的身份、权限和计费流程；请勿分享登录密码、验证码、会话 Cookie 或管理员权限。
这个页面现在是否已经提供可调用的 API？
当前为产品落地页和接入结构说明，并不表示已对外开放生产 API。上线真实中转能力前，还需要完成上游授权、鉴权、限流、用量计量、审计与滥用防护。
API RELAY, WITH CLEAR BOUNDARIES
先搭好接入层，
再让模型能力进入产品。
从密钥边界、接口契约到可观测性，构建一个可持续运营的 API 中转服务。
回到接入示例 ↑本页不提供账号代充值、账号共享或绕过平台规则的服务。