配額與速率限制
您能做多少，受兩樣獨立的東西限制：方案每日允許的搜尋次數，以及請求的速度上限。兩者都會在每個回應中報告，因此用戶端可以自行調節節奏，無須故意觸發錯誤才知道界線在哪裏。
速率限制：每分鐘十個請求
此限制按帳戶計算，由 API 與 MCP 伺服器共用：無論經哪個途徑，每分鐘最多十次呼叫。在時間窗口內的第十一個請求會立即返回 429 too_many_requests，並附上 Retry-After 標頭，指明還需等待多少秒才有空位。同一數字亦會以 error.retry_after 出現在回應內容中。
HTTP/2 429
Retry-After: 18
{ "error": { "code": "too_many_requests",
"message": "At most 10 requests per minute.",
"retry_after": 18 } }
等待 Retry-After 指定的秒數，然後重新發送請求。這次請求沒有消耗任何東西，也沒有用掉配額。
API 絕不會為了減慢您的速度而一直佔住連線。舊版匯出網址就會這樣做——每次暫停一秒，最長達半分鐘，然後才拒絕請求——這也是設立 API 的原因之一。
每日配額
您的方案每日允許一定數量的搜尋次數及程式碼片段請求次數，兩者分開計算。兩者都在下一個 UTC 午夜重設，而不是在使用後 24 小時。
- 每次搜尋從搜尋配額中扣除一次。
- 帶
snippets=1的搜尋則改為從程式碼片段配額中扣除一次。 /v1/account不消耗任何配額。
配額用完後，請求會被拒絕並返回 429 quota_exceeded 或 429 snippet_quota_exceeded，並附上上限、已用數量，以及距離重設還有多久。程式碼片段配額用完，不會影響一般搜尋。
結果深度
方案亦決定排名中有多少位置的結果可見——即 /v1/account 中的 disclosed_positions。超出此位置的項目會被略去，而不是留空；如有任何項目被略去，回應內容中的 truncated 會是 true，標頭中亦會有 X-Truncated: true。
這是 API 與網站之間最重要的分別。瀏覽器的配額用完時，網站會靜靜退回免費方案的深度，顯示較少結果——對於正在看網頁的人來說，這沒有問題。但腳本察覺不到這種變化，所以 API 會選擇拒絕，而不是縮短結果。
查看目前狀態
每個經身份驗證的回應都帶有五個標頭：
| 標頭 | 含義 |
|---|---|
X-RateLimit-Limit | 今日允許的搜尋次數。 |
X-RateLimit-Remaining | 今日剩餘的搜尋次數。 |
X-RateLimit-Reset | 當日配額重設的 Unix 時間。 |
X-Snippets-Limit | 今日允許的程式碼片段請求次數。 |
X-Snippets-Remaining | 今日剩餘的程式碼片段請求次數。 |
搜尋結果另外帶有三個標頭：
| 標頭 | 含義 |
|---|---|
X-Total-Results | 整個索引中符合的網站數目。 |
X-Returned-Results | 此回應包含的項數。 |
X-Truncated | 如方案的深度限制移除了部分項目，則為 true。 |
用量統計
/v1/account 一次呼叫即可提供完整資料，而且不消耗任何配額：
curl -H "Authorization: Bearer $KEY" https://api.publicwww.com/v1/account
{
"plan": "enterprise",
"plan_until": 1819461840,
"full_access": true,
"quota": {
"searches": { "limit": 300, "used": 12, "resets_at": 1787961600 },
"snippets": { "limit": 100, "used": 3, "resets_at": 1787961600 }
},
"limits": {
"disclosed_positions": 4294967295,
"disclosed_positions_snippets": 4294967295,
"max_per_page": 1000000,
"max_per_page_snippets": 10000
}
}
較舊的 https://publicwww.com/profile/api_status.xml?key=... 以 XML 報告同樣的計數，至今仍可使用。它屬於舊版網址；新程式碼應使用 /v1/account，它除了計數外，還會報告各項限制。