Transaction Communications and Access
Proof supports a number of implementation patterns for providing access to transactions.
Access Methods
Proof Email Communications
The standard path for providing transaction access is via emails sent automatically by Proof. All transactions require a signer email at a minimum. Once the transaction is activated (by calling the Activate Transaction endpoint or sending manually via the web application), signers will receiving an invitation email with basic instructions and a link to access the transaction. The email template is dynamic, showing and hiding metadata based on transaction setup (listing additional signers, handling signing order, displaying expiration dates, and more). This email template includes any logo set in your organization branding settings. Making changes to the template currently requires support from Proof - please reach out to Proof Support or your Professional Services consultant for assistance.
SMS
When you include a signer's phone number in the signer object or when sending manually via the web application, Proof will also send a SMS message to the signer. This message contains a similar link to begin the notarization session.
Transaction Access Links
Transactions will have a unique transaction_access_link returned for each signer when creating the transaction via API. You can chose to supply this link by embedding it in your application, redirecting a signer, or via your own communication channels (email, SMS).
Email Verification
Because signer accounts are uniquely identified by their email, Proof will always attempt to validate ownership of the email address provided for each signer.
Proof validates email addresses implicitly when a signer enters the transaction via a Proof email. When a signer enters the transaction through a
transaction_access_linkor SMS, they will be prompted to verify their email before continuing.This behavior can be disabled for transaction access links returned via API by setting
require_new_signer_verification : falsewhen creating the transaction. See Create Transaction for more details.
Suppressing Proof Communications
Customers that wish to provide a transaction_access_link through their own application or communication channels may wish to disable Proof communications.
Suppressing Emails
Emails can be suppressed at the transaction-level by setting suppress_email: true when calling the Activate Transaction endpoint.
Emails can also be disabled at the organization-level by Proof - contact Proof Support or your Professional Services consultant for assistance. Note: essential email communications such as password reset emails will be unaffected.
Suppressing SMS
SMS messages can be disabled at the organization-level by Proof - contact Proof Support or your Professional Services consultant for assistance.
Manually Triggering/Resending Proof Communications
Proof provides endpoints to manually trigger the transaction invitation email and SMS message:
Updated about 2 months ago