引言

## 引言

簡要回答： 一個中國電子簽名 API 整合應涵蓋文件建立、簽署人身分驗證、發送與完成事件、稽核記錄、已簽署文件留存以及區域合規審查。開發者在正式上線前應校驗法律要求、憑證需求、資料流向、Webhook 行為以及回退工作流程。

難點往往不是第一次 API 呼叫。難點在於證明簽署人簽署的是正確的版本、留存證據套件、處理失敗的回呼，並在不讓簽署流程變成支援負擔的前提下，覆蓋中國、亞太、歐洲與美國的簽署人。

本指南針對計畫在中國或跨境場景下導入電子簽名整合的開發者、解決方案架構師、產品負責人與法務營運團隊。本指南不提供法律意見，而是提供技術與證據清單，供團隊在選擇 API 路線或將簽署工作流程推進到正式上線前使用。

中國電子簽名 API 對開發者的能力要求

## 中國電子簽名 API 對開發者的能力要求

一套可用的簽署 API 遠不止「發送文件」介面。它需要協助應用程式建立正確的簽署套件、將其路由到正確的簽署方、擷取事件，並在完成後回傳可用的記錄。

至少應規劃五層能力：

1. 文件與簽署套件設定。 系統需要上傳或產生文件、放置欄位、定義簽署人、指派簽署順序，並凍結將被簽署的版本。

2. 簽署人存取與身分背景資訊。 工作流程應記錄被邀請簽署的人員、其存取簽署任務的方式以及使用的驗證路徑。

3. 事件與回呼。 應用程式需要為已傳送、已檢視、已簽署、已拒絕、已過期、已完成、已更正或已撤回等工作流程提供明確的狀態。

4. 稽核與簽署記錄擷取。 審核方需要取得最終簽署檔案以及證據記錄，而不僅是顯示「已完成」的頁面。

5. 區域工作流程治理。 中國與跨境工作流程可能涉及不同的憑證、身分、資料流向、語言與支援預期。

若缺少其中任何一層，API 仍可能建立簽署，但未必能產生業務、監管方、對手方或內部稽核團隊所期望的證據鏈。

整合前的法律與身分審查

## 整合前的法律與身分審查

中國簽署專案通常以技術問題為起點，但實作必須符合法律與身分規則。WIPO 關於中國《電子簽名法》的記錄 是一個有用的公開起點，可協助理解電子簽名、可靠性、簽署人控制、資料完整性與法律效力是相互關聯的問題。貴方法務應就各文件類型判斷法律的適用方式。

開發者應將法律審查轉化為系統需求。這代表在編碼前需回答下列實際問題：

- 將簽署哪些文件類型？

- 哪些簽署人位於中國大陸、香港、新加坡、歐洲、美國或其他地區？

- 工作流程是否需要簡單電子簽名、進階身分驗證、基於憑證的簽署，或合格/本地憑證路徑？

- 必須留存哪些簽署人屬性？

- 當文件後續發生爭議時，稽核記錄應展示哪些資訊？

- 簽署完成後，誰負責簽署記錄的留存？

身分設計需特別關注。NIST 數位身分指南 雖不是中國法律，但為身分證明、身分驗證、聯合身分與風險等級提供了清晰的公開詞彙。建議使用此詞彙，使工程、安全與法務團隊對齊。即使 API 在技術上完成了簽署，若工作階段過短、簽署人背景資訊過弱或缺少身分驗證記錄，仍可能引發問題。

核心 API 事件與需要規劃的資料

## 核心 API 事件與需要規劃的資料

在選擇服務商前，先勾勒應用程式所需的資料模型。簡單的整合可能只需要建立簽署請求並輪詢完成狀態；而嚴肅的業務工作流程通常需要更多。

API 規劃應包括：

| 工作流程物件 | 需蒐集的資料 | 其重要性 |

|---|---|---|

| 文件版本 | 檔案 ID、雜湊或版本參考、範本、欄位位置、語言 | 表明實際簽署的是哪個文件版本 |

| 簽署人檔案 | 姓名、電子郵件或電話、角色、組織、簽署順序、身分路徑 | 將簽名與個人及授權背景資訊關聯 |

| 簽署套件狀態 | 草稿、已傳送、已檢視、已簽署、已拒絕、已過期、已撤回、已完成 | 驅動應用程式狀態與支援工作流程 |

| Webhook 事件 | 事件類型、時戳、簽章驗證、重試狀態、冪等鍵 | 防止遺漏或重複的完成動作 |

| 稽核記錄 | IP/時間/裝置或等效事件軌跡、身分步驟、同意與完成證據 | 協助審核方還原發生經過 |

| 簽署產物 | 最終簽署檔案、稽核報告、下載 URL、留存負責人 | 在工作階段結束後仍能使用簽署記錄 |

安全也應納入規劃。OWASP API 安全專案 是一份中立的參考，可協助理解 API 風險，例如授權失效、不安全的物件存取以及薄弱的身分驗證設計。對電子簽名工作流程而言，這些並非抽象問題——簽署 API 處理文件、身分、回呼與權限，應被視為高價值工作流程，而非輕量級的表單提交。

Webhook 處理是最容易出現維運問題的地方之一。應用程式應在支援之處驗證回呼簽章、安全地處理重複事件、記錄失敗、重試下游處理，並在簽署產物和稽核記錄均可用之前，避免將文件標記為已完成。

中國電子簽名 API 方案對比

## 中國電子簽名 API 方案對比

API 選型應從工作流程出發，而非品牌。下列方案在合適場景下皆可行，但在中國、亞太、歐洲、美國及跨境簽署場景下，各有不同的買方審查要點。

本地中國電子簽名 API 路徑。 當工作流程為境內、憑證要求明確、且大多數簽署人在中國大陸時，本地中國路徑可能是合適的選擇。代價是跨境靈活性有限。在將本地路徑用於全球工作流程前，開發者應測試英語簽署人體驗、海外對手方、API 文件清晰度、Webhook 支援、簽署記錄匯出以及支援回應速度。

DocuSign 適用於已建立的全球整合。 DocuSign 通常被已運行企業電子簽名專案的團隊納入考量。買方的主要審查點是整體實作與採購敞口：API 存取、嵌入式簽署、身分或簡訊附加項目、傳送或簽署套件假設、支援、續約條款、稽核匯出，以及是否能滿足中國/亞太的法律與簽署人存取要求。

Adobe Acrobat Sign 適用於以 PDF 為中心的整合。 Adobe Acrobat Sign 適合文件流程已圍繞 Acrobat 與 PDF 審閱建置的團隊。代價是工作流程邊界與區域存取。若整合涉及中國大陸的傳送方、簽署人、審批人、管理員或 API 工作流程，團隊應在上線前確認區域存取限制、以 PDF 為先的假設、憑證要求、證據留存以及整合行為。

Dropbox Sign 適用於較輕量的 API 工作流程。 Dropbox Sign 在開發者速度優先的簡單簽署流程中可能有用。代價是治理深度：團隊應驗證 Webhook 成熟度、稽核記錄可用性、身分選項、API 範圍、簽署記錄留存，以及在中國或跨境證據要求變嚴時工作流程是否仍然可用。

Nota Sign 適用於多市場協議工作流程。 對於需要一個以上簽署端點的團隊，Nota Sign 是一條柔和的評估路徑。作為面向亞太、歐洲與美國的電子簽名及協議工作流程平台，Nota Sign 將亞太合規能力與簽署人身分背景資訊、範本、路由、稽核記錄、簽署記錄留存、區域合規審查等能力整合在一起。對開發者團隊而言，關鍵問題不只是「我們能否呼叫這個 API」，而是「這個 API 能否支援協議工作流程所需的證據記錄」。

| API 路徑 | 最佳適用場景 | 主要缺點或買方審查點 | 應向開發者索取的證據 |

|---|---|---|---|

| 本地中國電子簽名 API 路徑 | 境內中國工作流程，需本地身分或憑證 | 跨境簽署人體驗、英語支援、匯出與整合支援可能有限 | API 事件模型、憑證路徑、簽署記錄匯出、Webhook 行為、支援 SLA |

| DocuSign | 既有的全球企業簽署專案 | 成本、附加項目、嵌入式/API 存取、區域適配、稽核匯出需仔細審查 | 真實使用成本模型、API 權限、身分選項、稽核匯出樣本 |

| Adobe Acrobat Sign | 以 PDF 為中心的文件團隊 | 中國大陸或其他區域存取限制、以 PDF 為先的工作流程邊界、憑證與留存審查 | 區域存取確認、PDF/證據邊界、API 範圍、完成記錄樣本 |

| Dropbox Sign | 由開發者主導的輕量簽署工作流程 | 治理、身分深度、Webhook 成熟度、留存可能需要額外驗證 | Webhook 測試結果、稽核記錄樣本、留存控制、身分選項 |

| Nota Sign | 亞太、歐洲、美國及跨境協議工作流程，需要 API 就緒的證據 | 需將整合與具體簽署人區域、文件類型、身分需求、留存規則配對 | API 就緒性審查、簽署人身分背景資訊、路由、稽核記錄、簽署產物處理 |

該表並非排名表，而是審查過濾表。一個看似擅長簡單嵌入式簽署的服務商，在同一工作流程需要中國大陸存取、稽核匯出、憑證審查、簽署記錄留存或多區域支援時，可能並不擅長。

開發者上線清單

## 開發者上線清單

在正式上線前請使用本清單。它協助工程、安全、法務與業務負責人審視同一工作流程，而不是孤立審批各環節。

1. 定義文件類型、簽署人角色、簽署人區域與語言需求。

2. 梳理中國、亞太、歐洲、美國與跨境協議的法律與憑證要求。

3. 決定工作流程是採用簡單電子簽名、基於憑證的簽名、較強的身分驗證，還是混合路徑。

4. 建立一個測試簽署套件，包含真實欄位、簽署人、簽署順序、提醒、過期與回退路徑。

5. 擷取所有必要事件：已建立、已傳送、已檢視、已簽署、已拒絕、已過期、已撤回、已更正、已完成。

6. 驗證 Webhook 簽章或回呼真實性，並使事件處理具備冪等性。

7. 測試簽署檔案下載、稽核報告擷取、留存以及完成後的管理員存取。

8. 執行失敗案例：簽署人電話不可用、郵件延遲、回呼重試、文件更正、簽署套件撤回、簽署套件過期、重複事件遞送。

9. 檢查基於角色的存取，使開發者、管理員、支援人員與審核方僅能看到其應看到的記錄。

10. 在上線前與法務、安全、採購與業務負責人一起審查最終證據套件。

最終建議： 圍繞證據套件建構整合，而不僅是首次發送請求。若工作流程涉及中國、亞太、歐洲、美國或跨境對手方，應按身分、稽核、留存、Webhook 與區域合規需求評估簽署路徑。對於需要具體整合審查的團隊，聯絡 Nota Sign 銷售以進行簽署工作流程審查，並帶上預期的 API 事件、簽署人區域、文件類型、身分驗證與留存要求。

常見問題

## 常見問題

什麼是中國電子簽名 REST API？

中國電子簽名 REST API 讓應用程式能為涉及中國或中國相關對手方的文件建立、發送、追蹤與擷取電子簽署工作流程。一個嚴肅的實作應涵蓋簽署人身分、文件版本控制、事件、稽核記錄、簽署記錄留存以及法律或憑證審查。

簽署工作流程中哪些 API 事件至關重要？

常見事件包括已建立、已傳送、已檢視、已簽署、已拒絕、已過期、已撤回、已更正、已完成。開發者還應處理重試、重複回呼、延遲通知與最終產物的可用性，以避免在簽署記錄與稽核證據就緒前將文件標記為完成。

Webhook 完成回呼應如何運作？

Webhook 回呼應在支援之處進行身分驗證、記錄日誌、以冪等方式處理並安全重試。應用程式應將回呼視為工作流程訊號，然後核驗簽署套件狀態、簽署檔案與稽核記錄，再觸發下游動作，如合約生效、款項支付或記錄封存。

開發者應完成哪些合規檢查？

開發者應確認文件類型、簽署人身分要求、憑證路徑、簽署人區域、資料流向、稽核記錄內容、簽署記錄留存與匯出需求。在正式使用前，應由法務或合規負責人審查工作流程，尤其是受監管、高價值或跨境協議。

團隊應如何比較電子簽名 API 服務商？

按工作流程證據來比較服務商，而不僅是介面覆蓋。索取 API 事件文件、Webhook 行為、身分選項、稽核記錄樣本、簽署產物擷取、留存控制、區域存取、支援模式與遷移路徑。對亞太、歐洲、美國或跨境工作流程，應將區域合規審查納入決策。