Set up single sign-on

The Adobe Acrobat Sign Document API is designed to seamlessly integrate into your existing application without requiring you to go through a separate Acrobat Sign-managed registration process. Therefore, the enclosing application is responsible for ensuring that the sender is a registered Acrobat Sign user. It registers them programmatically through the API if they are not. Recipients are never required to register, and Acrobat  Sign always manages whatever interactions are necessary on the recipient side.

Specify a document sender

There are several ways to specify a sender when starting a new transaction with the sendDocument method. The behavior depends on what values are passed in through the optional SenderInfo parameter.

• Null SenderInfo: In this case, the sender of the document is the specific unique user associated with the API Key being used. This method is appropriate in testing and certain limited-scope implementations but is not typically useful for large-scale integrations with existing user sets.

• SenderInfo with email and password: In this case, the sender of the document is the user that the email parameter specifies. The password provided must match the user's Acrobat Sign password. For purposes of integration, the email and password can be solicited from the user within the context of the enclosing application when the document is about to be sent. Alternatively, the enclosing application can remember the email and password, either because the enclosing application created the user or because the user previously provided this information and it has been cached.

• SenderInfo with email and no password: In this case, the sender of the document is the user that the email parameter specifies. The password value must be null. Acrobat Sign verifies that the API caller and the intended sender belong to the same account, but doesn't require or check the password. This method is sometimes appropriate for API integrations within a specific organization, but it offers reduced individual security. This authentication model must be explicitly requested by the master account holder to be available for use through the Acrobat Sign API.

Acrobat Sign account management

As outlined above, in most cases you want to provide the email and password of the user on whose behalf you're sending the document. The following section outlines the different ways that information can be obtained.

Prompt the user

Prompt the user for their Acrobat Sign email and password as part of the sending process. You can use the verifyUser method to check that the user is registered with Acrobat Sign and the password is valid. If the user is unregistered, you can either ask them to create their own Acrobat Sign account or create one for them (see below).

Create the account

If a call to verifyUser shows that no user exists with that email address, you can programmatically create an Acrobat Sign user by calling createUser. Assuming the user creation is successful, the email and password that you provided can now be used as the SenderInfo for your document.

Remember the account

Subsequent to either of the scenarios above, you can then remember the user's email and password and use them as the SenderInfo for sending subsequent documents on behalf of that user. It's possible that the user will actually log in to their Acrobat Sign account and change their password at any time, so your application must be able to handle the case of a previously saved password being invalid.

Conclusion

There are a number of different ways to determine sender identity when using the Acrobat Sign Document API. Read the information above carefully to decide which method is appropriate for your application. If you have any questions, don't hesitate to contact us.