發布說明

每月呼叫額度大幅提升

相比保留期限，大家對呼叫額度的需求要多得多。因此我們整理了資料保留政策，把這部分餘力轉到了額度上。Basic 和 Pro 都提升 3 倍以上。

• Basic 每月 30,000 次 → 100,000 次，Pro 300,000 次 → 1,000,000 次
• 正式環境記錄至少保留 60 天（沙箱與此前一致，仍為 30 天）
• 使用統計照常保存，儀表板圖表保持不變
• 封存下載下線。保留期內的記錄仍可在日誌中查看
• 若要長期保存資料，請在記錄抵達時就取走 — 設定 Webhook，或透過 GET /api/v1/data/<your-slug>/poll 輪詢

輪詢有了專門的端點

想取得新記錄的用戶端只能反覆重讀清單端點的第一頁——依時間倒序，又沒有辦法指定「從什麼時候開始」，所以每次輪詢都會把同樣的記錄再取一遍，然後丟掉絕大部分。現在有了專用的輪詢端點：只回傳上次呼叫之後到達的資料，由舊到新，並且記住你讀到了哪裡。

• 新端點 GET /api/v1/data/<你的-slug>/poll — 上次呼叫之後建立的記錄，由舊到新，每頁最多 100 筆
• 把上一次回應中的游標原樣傳回即可，無需自己管理時間戳。首次呼叫可以用 since（一律為 UTC），也可以什麼都不傳，即從那一刻起開始訂閱
• 每次回應只會包含兩種游標中的一種：next_cursor 表示還有積壓，應立即再次呼叫；poll_cursor 表示已經追平，儲存它並等到下一個週期
• 最近約 60 秒會在佇列追平之前保留，所以記錄是被延後到下一次輪詢，而不是被跳過
• 重試和重啟可能重複投遞同一筆記錄，因此請依記錄 id 做冪等處理
• API 參考、沙箱主控台程式碼範例和整合文件均已同步

Webhook 重試次數在所有頁面統一了數法

先前不同文件對 Webhook 重試的數法不一致：有的只數重試次數，有的數總嘗試次數，同一套策略在不同頁面看起來像 5 次或 6 次。現在所有頁面給出同一個數字。接收方約定也寫清楚了當你這邊的處理失敗時該回傳什麼。

• 正式環境共 6 次嘗試——首次投遞 1 次 + 重試 5 次（30 秒·2 分·10 分·1 小時·4 小時）。沙箱環境約 12 分鐘內共 4 次
• 2xx 表示「我收到了」，而不是「處理成功了」——即使你這邊的處理失敗也要回傳它，並把該失敗記錄在你自己的系統裡
• 5xx 只用於它真正表達的情況：你的接收端或它依賴的服務暫時故障，稍後重新投遞同一筆記錄有可能成功
• 日誌頁面的重試徽章現在顯示 3/6 而不是 2/5——同一次投遞，按文件的口徑計數
• 投遞與重試的行為沒有任何變化，變的只是描述方式

Webhook 停止運作時，我們會寄信通知你

投遞中斷的 Webhook 是無聲的——資料照常儲存，所以在你翻日誌之前一切看起來都正常。現在，重試全部用盡時我們會告訴你。

• 信中會寫明是哪個端點、回應碼與失敗原因，以及接收伺服器回傳的回應內容——那是區分防火牆攔截與應用程式拒絕的唯一線索
• 一次抖動不會觸發。它在我們放棄投遞時寄出——正式環境用盡重試約需 5 小時，若回應是不再重試的永久性錯誤則立即寄出
• 無論失敗多少次，每個端點每天最多一封。信中也會告訴你資料仍安全儲存
• 免費方案同樣會收到。僅限正式環境的所有者 Webhook，協作者 Webhook 不在範圍內，因為你無法變更那個 URL
• 沒有復原通知，也沒有後續郵件——修好接收伺服器，下一次呼叫即可正常送達

事件通知功能已移除

將 Webhook 投遞失敗、用量門檻等事件推送到 Discord、Slack 或 Telegram 的功能已移除。真正需要的提醒早已透過電子郵件寄送，您不需要做任何操作。

• 端點詳情頁的通知卡片已移除，AI 工具也不再接受通知設定
• 用量警告、超出上限、部署申請與完成的提醒仍然透過電子郵件寄送 — 這部分沒有變化

投遞失敗的 Webhook 現在會顯示在日誌中

日誌頁面過去只顯示我們是否接收並儲存了請求。即使 Webhook 從未送達你的伺服器，也仍然顯示為成功，資料可能悄悄遺失。現在投遞失敗會出現在同一個頁面上。

• Webhook 欄會標示投遞失敗或仍在重試的呼叫，並顯示回應碼
• Webhook 失敗篩選可只看尚未送達你伺服器的呼叫
• 日誌詳情會原樣顯示你的伺服器回傳的回應內容 — 這是區分防火牆攔截與應用拒絕的唯一線索
• 包含自動重試在內，每次嘗試都會列出時間與耗時
• 只有失敗的投遞會被記錄，因此空白並不代表成功；未設定 Webhook 的端點不會顯示該欄

每個 Webhook 都帶簽章了

此前區分真實 Webhook 與偽造請求的唯一手段是固定的認證標頭——設定是選用的、每次請求值都相同，而且無法察覺內容遭竄改。現在每次投遞都會附帶 HMAC-SHA256 簽章，你可以驗證它。

• 簽章遵循 Standard Webhooks 規範，9 種語言的官方函式庫大約三行程式碼即可驗證
• 驗證是選用的——如果你已在接收 Webhook，在你啟用之前不會有任何變化
• 密鑰位於端點詳情頁的 Webhook 簽章密鑰，沙箱與正式環境各自獨立
• 重新簽發後舊密鑰仍有效 24 小時，你可以在不遺失投遞的情況下更新伺服器
• 透過你自己的回呼 URL 收到的 Webhook 同樣帶簽章

Webhook 重試從秒級延長到小時級

過去 Webhook 重試被困在單次請求內，3 次嘗試在 24 秒內就結束了，當機的接收伺服器幾乎不可能在這個時間窗內復原。現在重試已遷移到佇列。

• 逾時從 7 秒延長到 15 秒
• 正式環境約 5 小時內重試 5 次；沙箱環境約 12 分鐘內重試 3 次
• 新增 X-3minapi-Record-Id 標頭，在各次嘗試中保持不變——請用它判斷重複
• 除 429 外的 4xx 不再重試，包括 409——我們將其理解為「已收到」
• 失敗的投遞現在會被記錄——將在後續版本中於日誌頁面顯示

Google Sheets 整合已下線

為了專注於接收、儲存與轉發 API 資料這項核心能力，我們移除了 Google Sheets 整合。

• 既有試算表仍保留在您的 Google Drive 中 — 沒有任何內容被刪除
• 所有 API 記錄仍可在日誌、統計與封存中查看
• 試算表相關流程可透過封存的 CSV 匯出替代
• 已釋出 3Min API 先前取得的 Google Drive 權限

新增搜尋 (Search) 端點

透過 payload 中的文字尋找記錄的全新 API 端點。

• 不分大小寫的部分比對,最少 3 個字元
• 可指定時間範圍 — 未指定時預設最近 30 天
• 游標分頁(每頁 1-30 筆,預設 10 筆)

WordPress 外掛已上線(zip 安裝)

在 WordPress 頁面中無需撰寫程式碼即可建立輸入表單與資料檢視,並直接對接 3Min API。

• 以可下載的 zip 檔案發布(手動安裝)
• 自動產生表單/清單/單筆記錄檢視程式碼片段

• 查看 WordPress 外掛 →

新增清單 (List) 端點

不帶 record_id 呼叫 GET 即可取得最近的記錄清單。

• 依建立時間倒序
• 游標分頁(每頁 1-30 筆,預設 10 筆)

MCP 支援與 ChatGPT 外掛程式上架

AI 代理可使用自然語言直接呼叫您的 API。

• 為每個端點自動提供 MCP 伺服器
• 支援 Claude / Cursor / ChatGPT 外掛程式

• 在 ChatGPT 外掛程式中搜尋「3Min API」→

正式上線

3Min API 正式對外開放,提供免費/付費方案與指南文件。

封閉測試

以邀請制封閉測試啟動,僅限受邀的早期使用者使用。