2025年3月17日
引言
簡要回答： 一個中國電子簽名 API 整合應涵蓋文件建立、簽署人身分驗證、發送與完成事件、稽核記錄、已簽署文件留存以及區域合規審查。開發者在正式上線前應校驗法律要求、憑證需求、資料流向、Webhook 行為以及回退工作流程。
難點往往不是第一次 API 呼叫。難點在於證明簽署人簽署的是正確的版本、留存證據套件、處理失敗的回呼，並在不讓簽署流程變成支援負擔的前提下，覆蓋中國、亞太、歐洲與美國的簽署人。
本指南針對計畫在中國或跨境場景下導入電子簽名整合的開發者、解決方案架構師、產品負責人與法務營運團隊。本指南不提供法律意見，而是提供技術與證據清單，供團隊在選擇 API 路線或將簽署工作流程推進到正式上線前使用。
中國電子簽名 API 對開發者的能力要求
一套可用的簽署 API 遠不止「發送文件」介面。它需要協助應用程式建立正確的簽署套件、將其路由到正確的簽署方、擷取事件，並在完成後回傳可用的記錄。
至少應規劃五層能力：
- 文件與簽署套件設定。 系統需要上傳或產生文件、放置欄位、定義簽署人、指派簽署順序，並凍結將被簽署的版本。
- 簽署人存取與身分背景資訊。 工作流程應記錄被邀請簽署的人員、其存取簽署任務的方式以及使用的驗證路徑。
- 事件與回呼。 應用程式需要為已傳送、已檢視、已簽署、已拒絕、已過期、已完成、已更正或已撤回等工作流程提供明確的狀態。
- 稽核與簽署記錄擷取。 審核方需要取得最終簽署檔案以及證據記錄，而不僅是顯示「已完成」的頁面。
- 區域工作流程治理。 中國與跨境工作流程可能涉及不同的憑證、身分、資料流向、語言與支援預期。
若缺少其中任何一層，API 仍可能建立簽署，但未必能產生業務、監管方、對手方或內部稽核團隊所期望的證據鏈。
整合前的法律與身分審查
中國簽署專案通常以技術問題為起點，但實作必須符合法律與身分規則。WIPO 關於中國《電子簽名法》的記錄 是一個有用的公開起點，可協助理解電子簽名、可靠性、簽署人控制、資料完整性與法律效力是相互關聯的問題。貴方法務應就各文件類型判斷法律的適用方式。
開發者應將法律審查轉化為系統需求。這代表在編碼前需回答下列實際問題：
- 將簽署哪些文件類型？
- 哪些簽署人位於中國大陸、香港、新加坡、歐洲、美國或其他地區？
- 工作流程是否需要簡單電子簽名、進階身分驗證、基於憑證的簽署，或合格/本地憑證路徑？
- 必須留存哪些簽署人屬性？
- 當文件後續發生爭議時，稽核記錄應展示哪些資訊？
- 簽署完成後，誰負責簽署記錄的留存？
身分設計需特別關注。NIST 數位身分指南 雖不是中國法律，但為身分證明、身分驗證、聯合身分與風險等級提供了清晰的公開詞彙。建議使用此詞彙，使工程、安全與法務團隊對齊。即使 API 在技術上完成了簽署，若工作階段過短、簽署人背景資訊過弱或缺少身分驗證記錄，仍可能引發問題。
核心 API 事件與需要規劃的資料
在選擇服務商前，先勾勒應用程式所需的資料模型。簡單的整合可能只需要建立簽署請求並輪詢完成狀態；而嚴肅的業務工作流程通常需要更多。
API 規劃應包括：
安全也應納入規劃。OWASP API 安全專案 是一份中立的參考，可協助理解 API 風險，例如授權失效、不安全的物件存取以及薄弱的身分驗證設計。對電子簽名工作流程而言，這些並非抽象問題——簽署 API 處理文件、身分、回呼與權限，應被視為高價值工作流程，而非輕量級的表單提交。
Webhook 處理是最容易出現維運問題的地方之一。應用程式應在支援之處驗證回呼簽章、安全地處理重複事件、記錄失敗、重試下游處理，並在簽署產物和稽核記錄均可用之前，避免將文件標記為已完成。
中國電子簽名 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 能否支援協議工作流程所需的證據記錄」。
該表並非排名表，而是審查過濾表。一個看似擅長簡單嵌入式簽署的服務商，在同一工作流程需要中國大陸存取、稽核匯出、憑證審查、簽署記錄留存或多區域支援時，可能並不擅長。
開發者上線清單
在正式上線前請使用本清單。它協助工程、安全、法務與業務負責人審視同一工作流程，而不是孤立審批各環節。
- 定義文件類型、簽署人角色、簽署人區域與語言需求。
- 梳理中國、亞太、歐洲、美國與跨境協議的法律與憑證要求。
- 決定工作流程是採用簡單電子簽名、基於憑證的簽名、較強的身分驗證，還是混合路徑。
- 建立一個測試簽署套件，包含真實欄位、簽署人、簽署順序、提醒、過期與回退路徑。
- 擷取所有必要事件：已建立、已傳送、已檢視、已簽署、已拒絕、已過期、已撤回、已更正、已完成。
- 驗證 Webhook 簽章或回呼真實性，並使事件處理具備冪等性。
- 測試簽署檔案下載、稽核報告擷取、留存以及完成後的管理員存取。
- 執行失敗案例：簽署人電話不可用、郵件延遲、回呼重試、文件更正、簽署套件撤回、簽署套件過期、重複事件遞送。
- 檢查基於角色的存取，使開發者、管理員、支援人員與審核方僅能看到其應看到的記錄。
- 在上線前與法務、安全、採購與業務負責人一起審查最終證據套件。
最終建議： 圍繞證據套件建構整合，而不僅是首次發送請求。若工作流程涉及中國、亞太、歐洲、美國或跨境對手方，應按身分、稽核、留存、Webhook 與區域合規需求評估簽署路徑。對於需要具體整合審查的團隊，聯絡 Nota Sign 銷售以進行簽署工作流程審查，並帶上預期的 API 事件、簽署人區域、文件類型、身分驗證與留存要求。
