> You are reading the Docusign Developer Documentation. For clean Markdown of any page, append .md to the page URL. > > Documentation indexes by section: > - APIs and SDKs: https://docusign.docs.buildwithfern.com/docs/llms.txt > - Platform 101: https://docusign.docs.buildwithfern.com/platform/llms.txt > - Extension Apps: https://docusign.docs.buildwithfern.com/extension-apps/llms.txt > - Docusign CLI: https://docusign.docs.buildwithfern.com/docusign-cli/llms.txt > > Authentication (OAuth, JWT Grant, M2M): https://docusign.docs.buildwithfern.com/platform/auth > Webhooks and Connect: https://docusign.docs.buildwithfern.com/platform/webhooks > > OpenAPI specifications: https://docusign.docs.buildwithfern.com/openapi.json > MCP server: https://docusign.docs.buildwithfern.com/_mcp/server # Send On Behalf Of functionality > **Note** > > This page describes functionality for the older eSignature SOAP API. See [JSON Web Token (JWT) Grant authentication](/platform/auth/jwt) for information on how to impersonate a user for other Docusign APIs using OAuth 2.0. 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: 1. Open [eSignature admin](https://admindemo.docusign.com/admin-dashboard) and select **Settings** 2. Select **Permission Profiles** 3. Add or update a permission profile to add the following permissions: 4. Under **Admin Permissions** select **Allow All** 5. Under **User Permissions**, select **Allow view and manage envelope rights through API** and then **Allow send on behalf of other users through API** 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. * If the identifier is a properly formatted email address, the system conducts a look-up of the email address and user name (if provided) to see if that user is a member of the account. If membership in the account is not found, a Partner Authentication Failed exception is thrown. The account used for the check is the one associated with the account member’s login credentials (User Name email address and password). * If the identifier is not an email address (the identifier fails the regular expression test for an email), it is assumed that the identifier is a UID. A search is conducted for the UID in the Single Sign On (SSO) customer system and the email address and user name associated with the UID are retrieved from the system. Then the system conducts a look-up of the email address and user name to see if that user is a member of the account. If membership in the account is not found, a Partner Authentication Failed exception is thrown. The account used for the Single Sign On check is the one associated with the account member’s login credentials (User Name email address and password). ## Support SOBO in the eSignature REST API To support SOBO in the eSignature REST API or when migrating your app to use OAuth2, use the [JWT Grant](/platform/auth/jwt) 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](/docs/esign-rest-api/reference/users/users/list) to look up a user’s GUID ID from their email address. Users’ email to GUID ID mappings are fixed and should be cached. ## Functions supported and not supported by Send On Behalf Of The following Docusign SOAP API calls do not support SOBO: * Account Management APIs (AccountManagement.asmx) functions that authenticate using Distributor Code and Distributor Password (ActivateSalesforceInstance, ChangeAccountPricePlan, GetPlanGroupInformation, GetPlanPricingInformation, GetSuccessorPlanInformation, NewSocialAccount, NewAccount, and ResendAccountActivation) are not supported by SOBO. * Credential APIs (Credential.asmx) functions (Login, Ping, GetAuthenticationToken, and RequestSenderToken) are not supported by SOBO. All other API.ASMX/DSAPI.ASMX functions (i.e., API calls that require username/password authentication support) are supported by SOBO authentication. ## Send On Behalf Of SOAP examples 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. **`SOAP Header with Email Address`** ```xml title="SOAP Header with Email Address" [BILL- xxxx-xxxx-xxxx-211cef79e5f3][john.doe@docusign.com] 2988541c-xxxx-xxxx-xxxx-f2d324062ca3 password YYYYYYYY ``` **`Credential API Login with Email Address`** ```xml title="Credential API Login with Email Address" [BILL- xxxx-xxxx-xxxx-211cef79e5f3][john.doe@docusign.com;John Doe]test9@docusign.com XXXXXXXX YYYYYYYY ``` **`SOAP Header with Email Address and optional User Name`** ```xml title="SOAP Header with Email Address and optional User Name" [BILL- xxxx-xxxx-xxxx-211cef79e5f3][john.doe@docusign.com;John Doe] 2988541c-xxxx-xxxx-xxxx-f2d324062ca3 password YYYYYYYY ``` **`SOAP Header with SSO UID`** ```xml title="SOAP Header with SSO UID" [BILL-xxxx-xxxx-xxxx-211cef79e5f3][P134325] 2988541c-xxxx-xxxx-xxxx-f2d324062ca3 password YYYYYYYY ```