The Docusign Send On Behalf Of (SOBO) functionality allows a single user in an account to authenticate for other members of the account. When originally conceived, it was meant for sending fully defined envelopes only. Since then, most other API functions have been allowed, making this really an \"authenticate on behalf of\" function instead of just a sending function.
This authentication is especially useful for CRM and other integrations where the API client also maintains an account-with-multiple-members structure similar to Docusign. In this scenario, having a single user authenticate with Docusign relieves the API integration from knowing and storing individual user passwords within the client application.
The SOBO user, also known as the authenticating user, authenticates with Docusign on behalf of an operating user. Once authentication is passed, the operating user's user and member settings are used for all authorization functions.
The SOBO functionality is only available to accounts that use the eSignature API to send envelopes.
An admin can enable SOBO for a user using the following steps:
If user permissions are being set through the Classic Docusign Experience web application, the listed settings correspond to the Account-Wide Rights and Send On Behalf Of Rights (API) settings.
The Docusign SOAP API SOBO function can use the normal email authentication for the eSignature API. The SOBO identifier can be a properly formatted email address, with an option semicolon-delimited user name, or a User ID (UID), if using the Single Sign On (SSO) environment, that can be looked up in the Docusign SSO configuration.
To support SOBO in the eSignature REST API or when migrating your app to use OAuth2, use the JWT Grant OAuth flow. JWT authentication is used to impersonate an accounted user, which is the equivalent of the SOBO feature.
The only difference is that the JWT grant flow requires the user’s GUID ID, also called their API Username. You can use the Users:list API method to look up a user’s GUID ID from their email address. Users’ email to GUID ID mappings are fixed and should be cached.
"},"sys":{"type":"Entry"},"internal":{"type":"ContentfulAssemblyHtmlSection"}},{"id":"48dbacb4-ecfb-52e0-9467-6650da3abd2c","contentful_id":"6Pz17k6Q9gNZMogKkHEXdA","node_locale":"en-US","heading":"Functions supported and not supported by Send On Behalf Of","headingLevel":2,"sectionId":null,"multicolumn":false,"noBorder":false,"backgroundKind":null,"paddingTop":null,"paddingBottom":null,"html":{"html":"\n\nThe following Docusign SOAP API calls do not support SOBO:
All other API.ASMX/DSAPI.ASMX functions (i.e., API calls that require username/password authentication support) are supported by SOBO authentication.
"},"sys":{"type":"Entry"},"internal":{"type":"ContentfulAssemblyHtmlSection"}},{"id":"71a7b819-f50b-53a1-807a-49bce4c7d3b1","contentful_id":"5JkrvRZUsL6jDqczpLb62i","node_locale":"en-US","heading":"Send On Behalf Of SOAP examples","headingLevel":2,"sectionId":null,"multicolumn":true,"noBorder":false,"backgroundKind":null,"paddingTop":null,"paddingBottom":null,"html":{"html":"The examples in this section show the different ways the SOBO identifier is used for authentication in a SOAP Header. The most common use for SOBO is with one of the Docusign SOAP API methods for envelope sending methods, but for this example a RequestStatus method is used for brevity.
These examples use an integration key and Send On Behalf Of identifier, both included in separate brackets in the Email or Username objects. The Send On Behalf Of identifier is highlighted in the examples.