一个端点，
所有模型。
Tare 是挡在你所有模型前面的一层 OpenAI 兼容网关 —— 我们的，和你自己带来的。一个 base URL、一把 key，每一个 token 都算得清。
计费对账 API
对账 API
给机器用的账务接口：ERP、财务系统、内部看板可以直接拉数，无需模拟登录。
使用对账 Key，而非推理 Key
对账接口需要一把对账 key（integration key）——在控制台 API Keys 页新建， 类型选 Reconciliation；也可由平台代为签发。
⚠️ 三类 key 权限互不重叠，用错类型返回明确的拒绝而不是含糊的 401：
| Key 类型 | 权限 |
|---|---|
| 推理 key | 调用模型 |
| 对账 key | 读取报表，不能调用模型 |
| 母钥 | 管理 Key，既不能调用模型也不能读取账务 |
接口
Base：https://tare.jamerly.ai/v1/integration
| 路径 | 用途 |
|---|---|
/whoami | 这把 key 属于谁、当前账期、可访问的资源 |
/balance | 余额、授信额度、可用额度、累计充值与消费 |
/transactions | 流水，分页 |
/statements | 月度账单列表 |
/statements/{period} | 某一期的账单，如 2026-07 |
/usage/daily | 按天的用量，可按 apiKeyId 过滤 |
/attribution | 成本归因：按模型、渠道、标签拆分 |
/reconciliation | 平台账目与上游账单的差异 |
Code / Terminal
curl https://tare.jamerly.ai/v1/integration/balance \
-H "Authorization: Bearer $TARE_INTEGRATION_KEY"
粒度：余额账号级，用量可按 key
/balance 和 /transactions 是账号级的，同一账号下所有 key 共享一个钱包。
这与 key 的定位一致：一把 key 是一个账单单元，用量可按 key 拆分，余额共享。限制单把
key 的消费请用 母钥 的 limit，那是另一套机制。
用量按 key 拆分：/usage/daily?apiKeyId=…。
两个限制
- 单次查询窗口上限 100 天。 一年的对账分四次拉取，超出返回明确错误而不是静默截断——
一个从
from=2020-01-01起算的定时任务不应由数据库承担后果。 - 限流 1200 次/分钟，与模型流量分开计算。对账要按天、按 key、按模型翻上百页，按模型 那一档的阈值会在首次接入时就 429。
字段稳定性
这些接口的返回字段是对外契约，不会因内部重构而改名。需要 OpenAPI / JSON Schema 描述 文件见接口列表最后一节。
对账的两个前提
账期按某个时区切分。 2026-07 只是一个字符串，起始时刻并不自明，每个响应都会带上
切分所用的时区。若你侧按其他时区切分月份，月末当天的用量会落入不同月份，两边永远对不平，
且差额小到足以被误认为舍入误差。
迟到的更正计入下一期。 已锁定的账单不会被改写。如果你的 ERP 预期「更正到达后上个月的 数字会变」，那不会发生——请在当期查找补差行，它注明了来自哪个月。
文档最后更新于 2026 年 9 月 20 日 06:31（UTC+8）