Skip to main content

介面概述

日誌查詢介面返回你賬號下每一次 API 呼叫的明細記錄,包括呼叫的模型、實際扣費、耗時、 是否流式、以及失敗時的錯誤碼。 它和餘額查詢 API 是互補的:餘額查詢告訴你「現在還剩多少錢」, 日誌查詢告訴你「錢花在哪了」。 三類典型用途:

自動對賬

按時間段、按模型統計實際消費,與自己的業務賬單核對

故障自查

查失敗請求的錯誤碼,定位是引數問題還是上游問題

報障提工單

拿到 request_id 給客服,能精確定位到那一次呼叫
控制台也能看日誌(「日誌」頁面)。本介面是同一份資料的程式化入口,適合需要自動化對賬、 定時匯出、或接入自己監控系統的場景。手動檢視請直接用控制台,見 如何檢視我的呼叫記錄

如何獲取系統令牌

日誌介面用系統令牌認證,與 API Key 不是一回事(詳見文末注意事項)。
1

訪問控制台

訪問 api.apiyi.com/account/profile 個人中心頁面
2

找到系統令牌

在頁面最下方找到「賬號選項 - 系統令牌」部分
3

生成 AccessToken

輸入當前的賬戶密碼後,會得到一個 AccessToken,該金鑰可用於後續介面的查詢資料
獲取系統令牌

介面資訊

請求說明

請求 Headers

查詢引數

page_size 的實際上限是 10。page_size=100 也只會返回 10 條 —— 這不是報錯, 很容易被誤認為「我這段時間只有 10 次呼叫」。拉取任何有意義的時間段都必須翻頁, 翻到返回空陣列為止。下方的 Python 與 Node.js 示例已經處理好翻頁。

日誌型別 type

統計花費時務必帶上 type=2 不傳 type 會把充值、系統贈送記錄一起返回, 這些記錄的 quota 雖然是 0,但 model_nametoken_name 也是空的, 直接遍歷求和或按模型分組會得到錯誤結果。

響應說明

成功響應示例

關鍵響應欄位

other 欄位存的是一段 JSON 字串而不是巢狀物件,取用前需要再解析一次 (Python 用 json.loads(),JavaScript 用 JSON.parse())。裡面包含 billing_type(計費方式)、request_path(實際呼叫的端點)、group_ratio(分組倍率)、 model_ratio(模型倍率)、usage(用量明細)等。

額度換算

換算規則

500,000 額度 = $1.00 美金 (USD)
計算公式: 美金金額 = quota ÷ 500,000 示例:
  • quota: 7500 → $0.015 USD
  • quota: 22500 → $0.045 USD
  • quota: 18 → $0.000036 USD
這與餘額查詢 API 是同一套換算口徑,可以直接對齊。

錯誤響應

HTTP 401 - 認證失敗

原因: 系統令牌無效、已過期,或誤把 API Key(sk- 開頭)當成系統令牌使用。 解決方法: 回控制台重新生成系統令牌,確認 Authorization 裡填的是不帶 Bearer 字首的裸值。

程式碼示例

cURL 示例(單頁,快速驗證)

必須新增 --compressed 選項,因為 API 返回的是 gzip 壓縮內容,否則會得到亂碼。
這條命令只能拿到 10 條。真正對賬請用下面帶翻頁的完整版。

Python 示例(帶翻頁,可直接執行)

輸出示例:

Node.js 示例(帶翻頁)

fetch 會自動處理 gzip 解壓,Node.js 側無需額外配置(Python 的 requests 同理)。 只有 curl 需要顯式加 --compressed

典型場景

場景一:統計某段時間的花費

用上面的 Python 示例,關鍵是type=2 並把 quota 求和後除以 500,000。 如果只想看某個模型,加 model_name 引數即可。

場景二:找出失敗的呼叫

被閘道拒絕的請求(引數錯誤等)quota 為 0,不產生扣費。日誌裡能看到 error_code, 方便你區分「呼叫失敗了」和「呼叫成功但結果不滿意」。

場景三:報障時提供 request_id

在日誌裡定位到出問題的那次呼叫,把 request_id 提供給客服,可以精確查到該次請求的 完整鏈路。這比描述「大概幾點呼叫 xx 模型失敗了」高效得多。

常見問題

page_size 的服務端上限就是 10,傳更大的值不會報錯但也不會生效。 需要拉更多資料必須翻頁(p=0p=1p=2 …),翻到返回空陣列為止。 上面的 Python 與 Node.js 示例已經封裝好這個邏輯。
不是。部分欄位屬於平臺內部資訊,普通賬號視角下為空或 0,屬正常現象, 不影響對賬與排障需要的欄位(quotamodel_nameerror_coderequest_id 等都是完整的)。
介面返回的是分組的識別符號,控制台顯示的是分組的展示名,兩者可能不同。 例如介面返回 default,控制台顯示「Default」。完整的對應關係可以從公開介面 https://api.apiyi.com/api/pricingusable_group 欄位獲取,它是一個「識別符號 → 展示名」的對映表。如果你要讓自己的報表和控制台顯示一致, 需要自己做一次對映。
quota 為準。quota 是本次呼叫實際扣除的額度,是唯一可用於對賬的欄位。 響應體裡的 token 數在部分按次計費的模型(如出圖、影片類)上可能是佔位值, 不參與計價 —— 這類模型的計價方式在 other.billing_type 裡會標為 by_count
通過 start_timestamp / end_timestamp 指定時間範圍即可。 具體的歷史資料保留期請諮詢客服。建議對賬資料定期匯出留存,不要長期依賴介面回查。
原因: API 返回的是 gzip 壓縮內容(Content-Encoding: gzip),curl 沒有自動解壓。解決方案: 新增 --compressed 選項:
Python 的 requests 與 Node.js 的 fetch 會自動解壓,無需額外配置。
不會。日誌查詢介面不消耗任何配額。

注意事項

系統令牌不是 API Key,兩者不能互換
  • API Keysk- 開頭)用於 /v1/* 推理端點,拿去調 /api/log/self 會返回 401
  • 系統令牌(一串不帶字首的字元)用於 /api/* 管理端點,拿去調 /v1/chat/completions 會返回 Invalid token
系統令牌的權限範圍覆蓋整個賬號,請像保管賬號密碼一樣保管它:存進金鑰管理工具而不是程式碼, 不要提交進程式碼倉庫,定期輪換。
日誌響應裡含有你自己的 API Key 明文日誌記錄會返回發起該次呼叫的令牌資訊。不要把日誌的原始響應直接貼到公開場合、 截圖發群、或轉交給第三方,匯出前先剔除敏感欄位。特別提醒:這段明文不帶 sk- 字首,常見的金鑰掃描工具可能掃不出來, 不要依賴自動化檢查兜底。
請求限制
  • 建議查詢間隔不少於 1 秒,避免頻繁請求觸發限流
  • 建議設定合理的請求超時時間(推薦 30 秒)
  • 大範圍時間段的拉取請做好翻頁與重試處理

相關文件