API 限額對比：DocuSign vs HelloSign（Dropbox Sign）

簡短回答：DocuSign 與 HelloSign 採用不同的限額模型

DocuSign 與 HelloSign（現為 Dropbox Sign）對 API 用量的計量方式完全不同，因此並不存在一個可以直接對比的「API 限額」數字。DocuSign 官方文件描述的是每個帳戶的每小時請求上限（預設每小時 3,000 次，透過 X-RateLimit-Limit 響應頭暴露）、30 秒突發上限（開發環境 200 次、生產環境 500 次），以及嚴格的輪詢紀律——每個信封的狀態查詢每 15 分鐘不超過一次。HelloSign / Dropbox Sign 官方文件描述的則是每分鐘請求速率（標準請求每分鐘 100 次、高級端點 25 次、測試模式 10 次）；更關鍵的是，它把端點按計劃層級劃分：嵌入式簽署與批量發送在 Standard 計劃解鎖，模板編輯 API 在 Premium 計劃解鎖。

對於要拿這兩個 API 承載每月數千份合約的開發者來說，可靠的答案不是一個營銷數字，而是一套核實流程：讀官方文件、檢查自己的響應頭、做壓測。兩個概念必須分開：速率限制（每分鐘或每小時允許多少次 API 請求——這是技術性節流）和信封配額（你的計劃每月包含多少份文件——這是商業性額度）。團隊選錯供應商，往往就是因為把兩者混為一談。帳單側的問題，我們關於 DocuSign 與 Dropbox Sign API 成本與定價層級對比的評測展示了這兩個數字如何變成合約條款。

DocuSign API 限額：官方文件到底怎麼說

DocuSign 的權威說明集中在兩處：平台級的 API 資源限額頁面 和 eSignature 專屬的 規則與資源限額頁面。按現時文件，機制如下：

• 每帳戶每小時上限。 所有 DocuSign API 都會將每個帳戶限制為每小時一定次數的請求，透過 X-RateLimit-Limit 返回；文件預設值是 3,000 次，每小時整點刷新。符合資格的帳戶可由管理員透過 API Usage Center 提高該上限。
• 30 秒突發上限。 開發環境每 30 秒 200 次，生產環境 500 次（X-BurstLimit-Limit）。
• 單信封紀律。 每個信封每小時的 GET/PUT 請求受限，單個應用對同一信封的狀態查詢最多每 15 分鐘一次；反覆輪詢會被標記，並可能在 Go-Live 審核中導致應用失敗。文件建議用 DocuSign Connect（webhooks）替代輪詢，並建議每次信封建立或更新調用約 5 次以內。
• 上載並發限制。 同一文件的並發上載會被節流——文件描述為最近一小時內同一文件最多 70 個進行中的上載。

DocuSign 可能隨時修訂這些數字，因此請以網上 rules-and-limits 頁面以及你自己帳戶上的 X-RateLimit-* 響應頭為事實來源。如果你已經透過 API 拉取已簽署文件數據，從已簽署文件中提取表單欄位數據一文介紹了對輪詢友好的做法。

HelloSign（Dropbox Sign）API 限額：官方文件到底怎麼說

HelloSign 在 Dropbox 收購後更名為 Dropbox Sign，權威文件位於 developers.hellosign.com/docs/overview。現時機制如下：

• 每分鐘請求速率。 標準請求每分鐘最多 100 次，高級請求每分鐘 25 次；測試模式每分鐘 10 次。限額透過 X-Ratelimit-Limit、X-Ratelimit-Limit-Remaining 和 X-Ratelimit-Reset 頭暴露；超限時返回 HTTP 429 與 exceeded_rate 錯誤。
• 端點按計劃分級。 這是與 DocuSign 的結構性差異。Essentials 解鎖核心發送（signature_request/send、send_with_template）；Standard 解鎖批量發送與嵌入式簽署（bulk_send_with_template、create_embedded、create_embedded_with_template、bulk_create_embedded_with_template 以及 unclaimed_draft 系列）；Premium 解鎖嵌入式模板編輯（template/create_embedded_draft、template/update_files）。
• 測試模式與超額。 幾乎所有功能都可以在免費帳戶上用 test_mode: true 測試（帶水印、不具法律效力）。頻繁觸發速率限制會收到電郵警告，並可能導致帳戶被封鎖；如需提高額度可申請。

該頁面沒有說明的，是每個計劃的每月信封配額——那是 Dropbox 定價與銷售材料裡的商業數字，因此網誌上任何具體的每月信封數字，在獲得書面確認之前都應視為未經證實。對日常簽署流程來說，HelloSign 與 DocuSign 的簽署流程對比是很有用的補充閱讀。

嵌入式簽署與模板 API：兩家的計劃在哪裡分岔

對產品團隊來說，最棘手的限額通常不是吞吐量，而是你的計劃開放了哪些端點。Dropbox Sign 的分層很明確：在自己的應用內嵌入簽署至少需要 Standard（create_embedded、create_embedded_with_template），以編程方式建立或編輯模板需要 Premium（template/create_embedded_draft、template/update_files）。批量發送同樣在 Standard。評估用 Dropbox Sign 做嵌入式產品的團隊，必須首先核對計劃層級，而不僅是請求速率。

DocuSign 把同樣的能力——嵌入式簽署、批量發送、PowerForms、模板、Connect webhooks——都歸在同一個 eSignature API 面上，但你的訂閱包含哪些，由協商確定的商業計劃決定，而不是以固定清單發佈。可靠的確認方式是在開發者沙箱裡測試、跑一遍 DocuSign 的 Go-Live 審核，並閱讀自己的計劃文件。想按地區了解，面向 APAC 團隊的 DocuSign 與 Dropbox Sign 對比說明了這些能力差異在實際中的表現。

這些限額對高吞吐量與批量簽署意味著什麼

當每月要處理數千份合約時，把兩家的機制轉化為設計約束：

• 用批量端點，而不是逐信封循環。 Dropbox Sign 的 bulk_send_with_template（Standard）是官方的批量路徑；DocuSign 文件建議每個信封約 5 次調用、用 Connect 查狀態。輪詢循環是觸發 15 分鐘規則和每小時規則的最快方式。
• 按突發設計，而不是按平均設計。 一個在兩分鐘內發出數千次調用的批次處理任務，會在業務配額耗盡之前先撞上 DocuSign 的 30 秒突發上限（示範 200 / 生產 500）和每小時上限。把工作攤開，或透過 API Usage Center 提高每小時上限。
• 用 webhooks 替代輪詢。 DocuSign Connect 和 Dropbox Sign 回調，是兩家平台自己給出的狀態檢查方案。
• 把配額與速率分開。 每月幾千份合約在信封層面並不算多，但每份合約可能產生 20–50 次 API 調用（建立、收件人更新、文件下載、狀態查詢）。真正撞上限額的是這個乘數，而不是原始合約數量。
• 壓測時要尊重測試模式節流。 Dropbox Sign 每分鐘 10 次的測試上限意味著，貼近真實的壓測需要付費帳戶並逐步提升速率。

對於輕量、偶發的使用場景，計算方式又不一樣了——一次性簽署場景的最佳 DocuSign 替代方案討論了什麼時候完整的 API 平台屬於殺雞用牛刀。

對比表與核實清單

落單之前先過一遍清單：（1）閱讀兩家供應商現時官方的速率限制頁面；（2）讀取你自己帳戶的 X-RateLimit-* 響應頭；（3）從定價頁或客戶經理那裡書面確認每月信封配額；（4）確認你需要的具體端點（嵌入式、批量、模板）所在的計劃門檻；（5）在生產級帳戶上跑一次受控壓測，留意 429 和 HOURLY_APIINVOCATION_LIMIT_EXCEEDED；（6）在動手開發前就按 webhooks 而非輪詢來設計；（7）在評估文件裡給核實過的數字標上日期，讓工程和採購共用同一個事實來源。

第三個基準：Nota Sign 的按量模式

如果上面的限額對比讓你想再找一個選項，可以把 Nota Sign 放上同一條測試線。它背後是法大大（FaDaDa）——連續多年被 IDC 評為中國電子簽名軟件市場第一——平台完成的簽署在 100 多個國家和地區具有法律效力，亞太合規覆蓋從 iAM Smart、Singpass 一直到 SES/AES/QES 各保障級別。

與上面兩家相比，真正的分野在商業模型：沒有按席位授權。工程團隊就算發送人翻倍，成本也不隨之翻倍；方案按月度文件量設計，正適合本文討論的高吞吐批量場景。用你自己的負載特性去實測——向 Nota Sign 團隊索取按量報價。