概觀

您不需執行各個 eSign 服務所管理的註冊程序,便能順暢地將 Document Cloud eSign 服務文件 API 整合至現有應用程式之中。因此,內部應用程式必須負責確認寄件者為 eSign 服務的註冊使用者。若寄件者非註冊使用者,則會依程式並透過 API 為其註冊。收件者無須註冊,但 eSign 服務會一律管理收件方的必要互動。

指定文件寄件者

您可透過下列數種方式,在使用 sendDocument 方法開始進行新的交易時指定寄件者。該行為是取決於透過選用的 SenderInfo 參數所傳入的值。

  • 空的 SenderInfo 值: 在此情況下,該文件的寄件者就是與使用中 API 金鑰相關聯的特定唯一使用者。此方法適用於測試和特定有限範圍的實作作業,一般來說不適用於現有使用者集合的大規模整合作業。
  • 使用電子郵件和密碼的 SenderInfo: 在此情況下,文件寄件者為電子郵件參數指定的使用者。提供的密碼必須符合使用者的 EchoSign 密碼。為了進行整合作業,您可以在準備傳送文件時,在內部應用程式的範圍內徵求使用者的電子郵件和密碼。另外,由於內部應用程式已建立使用者,或使用者已於先前提供此資訊且該資訊已快取,因此該程式可記住電子郵件和密碼。
  • 使用電子郵件但不使用密碼的 SenderInfo: 在此情況下,文件寄件者為電子郵件參數指定的使用者。密碼值必須為空值。EchoSign 會確認 API 呼叫者與預定寄件者同屬同一個帳戶,但不會要求或檢查密碼。此方法有時適用於特定機構內的 API 整合作業,但會造成個人安全性降低。此驗證模式必須經主帳戶持有人明確要求,才可透過 EchoSign API 使用。

eSign 服務帳戶管理

如以上概述所示,在大部分的情況下,當您代替使用者傳送文件時,需要提供其電子郵件和密碼。下一個區段會概述取得資訊的各種方式。

提示使用者

提示使用者 eSign 服務的電子郵件與密碼為傳送程序的一部分。您可以使用 verifyUser 方法查看使用者是否已註冊 eSign 服務,以及其密碼是否有效。如果使用者未註冊,您可以要求他們建立自己的 eSign 服務帳戶,或為他們建立帳戶 (如下所示)。

建立帳戶

如果呼叫 verifyUser 時顯示並無任何使用者註冊該電子郵件地址,您可以透過呼叫 createUser 的方式來依程式建立 eSign 服務使用者。假設已成功建立使用者,則您所提供的電子郵件和密碼便可用來作為您文件的 SenderInfo。

記住帳戶

帳戶建立之後,您便可以記住使用者的電子郵件和密碼,並作為 SenderInfo 使用,代替該使用者傳送後續文件。由於使用者可能會隨時登入其 eSign 服務帳戶並變更其密碼,因此您的應用程式必須能夠處理先前儲存之密碼已無效的情況。

結論

使用 eSign 服務文件 API 時,有幾種不同的方式可以判斷寄件者身分。請仔細閱讀以上資訊,以決定您應用程式適用的方法。如果您有任何問題,請立即與我們聯絡

此産品由 Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License 授權  Creative Commons 條款未涵蓋 Twitter™ 與 Facebook 文章。

法律說明   |   線上隱私權政策