先界定資源及客戶工作
整個 API 共用一個請求次數上限，通常不足以反映每項請求啟動的工作。一次目錄查詢可能由快取回答；一次報表要求卻可能掃描資料庫及產生檔案。OWASP 把不受限制的資源耗用列為 API 風險，建議按業務需要調整互動頻率、資料大小及其他資源的限制。先問合作夥伴要完成甚麼：結帳時查存貨、夜間匯入目錄，還是建立不能漏掉的訂單？逐項寫明操作、正常請求模式及延誤後果，再列出受限資源，例如處理器、資料庫連線、背景工作名額、收費的下游呼叫、儲存或頻寬。這樣才能解釋為何某一路由需要限制。高成本匯出可比輕量讀取更嚴格，同時保留緊急訂單確認能力。真正的上限須靠本地流量和容量證據制定，標準或文章都無法給出通用的每分鐘請求數。
清楚界定誰使用配額
限制必須有明確對象。對已驗證的合作夥伴 API，以合作夥伴或應用程式憑證作主要識別通常合理，但一組憑證可能由多個安裝共用，同一企業也可能持有多把金鑰。只按 IP 地址限制，可能把共用網絡的不同顧客混在一起，亦可能漏掉分散來源的客戶端。要決定配額屬於機構、應用、用戶、操作、目的帳戶，還是多項組合，並記錄輪換憑證時配額如何延續。除非屬明確商業政策，否則不應讓夥伴靠增加金鑰數目倍增額度。未驗證端點亦須按濫用風險設防。同時把授權與速率限制分開：請求未超額，不代表它可讀取其他顧客資料。要說明驗證失敗是否計入保護性配額，避免一個惡意來源耗盡正常用戶共享的額度。
除了頻率，還要限制單次成本
客戶端即使沒有超過每分鐘請求上限，仍可能透過巨大分頁、深層查詢或同時啟動大量高成本工作耗盡系統。OWASP 的 API 指引也要求限制資料大小及參數，其例子說明單靠請求計數會漏掉批次工作的成本。視乎端點，應限制每頁紀錄數、上傳大小、報表日期範圍、批次項目數和同時執行的工作數。按端點量度排隊時間及資源耗用，不要假設每個請求成本相同。服務級別宜少而清晰，讓夥伴容易理解。企業可以安排批量匯入時段，但必須明確授額並監察，而非靜悄悄繞過所有安全限制。文件要交代哪些工作即時完成，哪些先回傳工作編號供稍後取回。若下游供應商按呼叫收費，亦須計入成本風險。政策應寫清楚哪種工作會被拒絕、排隊，或接受後延遲處理。
讓超額回應可理解及可恢復
RFC 6585 把 HTTP 429 定義為用戶在某段時間內送出過多請求，並指出回應應解釋情況，可附 Retry-After。RFC 9110 規定 Retry-After 可用秒數或 HTTP 日期表示等待時間。真正觸及相關政策時才使用 429，並回傳安全、穩定的錯誤內容，指出涉及哪項操作或配額。如果伺服器能合理估算等待時間，可提供 Retry-After；若同時工作名額取決於無法預測的任務完成時間，就不要虛構精確的重開時刻。尤其對寫入操作，須說明被拒請求是否曾執行。若建立訂單的首次嘗試是否成功不明，客戶端便不能安全重試。錯誤訊息不可洩露其他租戶的流量、帳戶識別或秘密設定。閘道與應用程式應使用一致的回應格式，免得客戶端猜測 JSON 錯誤、HTML 頁面及斷線是否同一回事。
啟用限制前先設計客戶端反應
守規矩的客戶端收到 429 後應停止密集重試；如有有效的 Retry-After，應按其提示等待，並在大量客戶端可能同時醒來時加入有限度的錯開。重試政策須設最長等待、最大嘗試次數，以及提示人手處理或稍後恢復的方法。不能把所有寫入失敗都當作可安全重做；寫入操作的冪等處理及結果查詢要另行設計。讀取存貨時，略舊的快取資料是否可接受，須由業務決定，畫面亦要如實標示。關鍵訂單可能更適合進入排隊狀態或由職員跟進，而非直接丟失。合作夥伴文件要說明這些路徑，並用範例客戶端測試。客戶端控制還須避免大量同步重試把短暫限制變成持續故障。失去網絡回應與明確收到 429 亦要分開處理，因為失去回應不能證明伺服器拒絕了操作。
以合作夥伴情境核對政策
假設零售商向一名物流合作夥伴開放存貨查詢及報表匯出。促銷期間查詢量急升，夥伴同時啟動多份大型歷史報表。若所有端點共用一個上限，可能令結帳所需的存貨查詢被擋。較合理的設計是替昂貴匯出設定較小的同時工作額度及有限日期範圍，讓查詢使用按實際容量量度的另一組配額。匯出名額用完時，新請求按照文件收到拒絕或排隊回應；如果已接受延後處理，則給出工作編號。合作夥伴的程式按合約等待，其他獲准操作繼續運作。職員觀察被拒次數和真實資源壓力；正常工作若反覆延誤，就與夥伴檢討門檻。這只是設計情境，不代表實際零售商觀察結果，也不是建議某個數字。它說明政策應與操作成本及等待對顧客的後果連結。
根據證據逐步啟用
設定初步門檻前，應收集具代表性時段的請求量、突發流量形狀、延遲、錯誤率、租戶組合及資源耗用，涵蓋一般高峰和已知批次時段；平均數會掩蓋真正重要的尖峰。記錄請求所屬已驗證對象和路由，但日誌應合乎比例，避免儲存敏感內容。先在測試或觀察階段計算建議政策會擋住哪些正常請求，再按已記錄的業務需要調整。透過既有合約溝通渠道告知夥伴政策、錯誤格式及預定啟用日。可先設警示，架構容許時再限量啟用，並同時留意容量與夥伴完成工作的情況。緊急斷路措施可能需要比日常商業額度更嚴格的獨立規則。亦要記下誰可改門檻、改多久及原因，避免一次例外變成隱形的永久弱點，或令某客戶得到不公平待遇。
測試邊界及失敗後恢復
有效驗收要測試每個上限以下及以上的情況，並涵蓋兩名夥伴、兩種操作和憑證輪換。檢查一名夥伴不能耗用另一人的配額、批次工作不能繞過成本上限，而同時抵達的請求不會因計數器更新太遲而全部通過。核實 429 狀態碼、安全的回應內容、提供時的 Retry-After 格式，以及文件記載的客戶端反應。模擬寫入請求失去回應，確認客戶端可查得結果而不建立重複業務紀錄。再模擬閘道重新啟動或分散式計數器故障，按每種操作風險定義失效時容許還是拒絕請求；不同操作未必採同一選擇。上線後同時檢視拒絕率和資源是否飽和。拒絕很少但資料庫耗盡，不算成功；大量正常請求被拒，則可能門檻太緊。目標是有觀察證據支持、能持續運作且可調整的顧客流程。
正式採用前的核對
- 每項配額均寫明對象及操作。
- 按客戶端合約驗證 429 及提供的 Retry-After。
- 把寫入失去回應與明確被限速分開測試。
