There is a guide on the Docusign website (https://developers.docusign.com/docs/esign-rest-api/how-to/request-signature-in-app-embedded-cfrpart11/) for this, but I keep getting the error "This Account lacks sufficient permissions. In-Session permission required when specifying a captive recipient." which suggests that embedded signing is not possible.
Has anyone been able to use the guide above?
CFR Part 11 is possible with embedded signing but as the how to guide shows you will need to use the SMS for access & signatures authentication method.
Running this example requires that you have a CFR Part 11 account with the "SMS for access & signatures" authentication method enabled.
You can contact DocuSign Support to get that enabled.
Related
I have been trying to implement JWT Auth grant for our back end application which will be creating URLs for signing operations for our end users.
What I want to active is that there will be no login/granting consent operations while sending the envelopes and creating signing URL. I want to dedicate one user for creating envelopes and sending them for signature.
Firstly, I've created a demo account and an organization. I also created an integration key and a RSA key. I needed to choose Implicit Grant or Authorization Code Grant while creating the integration key and I chose Implicit Grant. Lastly, I gave signature impersonation permissions to the integration key.
I have checked and made experiments with jwt example project after configuring with the required info of the user that I want to dedicate. It asked for the consent. After I gave consent, it worked finely. Then I configured the back end with the same integration key and the guid of the user, again it was working with our back end application that I was able to send automated envelopes.
I created another demo account in DS and this time I directly put it to our back end, I am getting consent_required error which I understand that I couldn't give the admin consent properly and it was just working with previous demo account because I gave the consent to that.
I want to know that how long that consent would last. or Is it the correct way to achieve what I want? because I think, ideally, I need to give admin consent to this dedicated user to have it able to send automated envelopes.
Thank you a lot in advance.
I see two questions:
How long consent would last? - forever. Or if you go and explicitly remove it.
Is it the correct way to achieve what I want? I don't know what you want, but the title says "Sending envelopes from one dedicated user" so, in theory that is correct. However, keep in mind that that user will be different when you move to production ("go live") when your application is ready for real usage.
My use case is thus:
I will have access to a single DocuSign account which would belong to Acme Inc. (I am currently using a sandbox account).
Acme Inc. has many branches, each with it's own employees with different documents that they must sign depending on which branch they work in.
From my internal application, the Admins of the branches will upload documents and set the emails addresses that the documents must be sent to.
The employees will complete the signing ceremony after following the link in the mail that they will receive.
MAIN ISSUE - Once the signing ceremony is complete, I require the employee to be redirected to a certain page of the internal application where they must complete some additional steps.
What I have so far:
I ran the example provided here. The issue with this is the permission request. I do not want an access prompt, rather, I want this done in the Admin Panel itself so that requests to the DocuSign API from my Server Application contain a valid token or receive a new one in case the existing one has expired. I saw from here that the JWT Grant system fit my use case, and I ran that using consent from a single user, however, I am stuck trying to figure out how to redirect the signer (employee) to the page I want with some parameters in the redirection URI. This can be as simple as the one provided (state=123) in the (eg-01) Embedded Signing example provided with the Auth Grant sample.
I apologize for not having any code snippet to show as I have not integrated anything into my internal application as of yet, I am merely running the code from the GitHub examples. Please let me know if I need to provide any additional information in order to facilitate your understanding of my requirements.
Any help provided would be much appreciated!
I think your main issue is the authentication type you are using.
You used the example showing Auth Code Grant, which does require users to log in.
You could instead use JWT (JSON Web Token) which does not require that (only once, and that can be done by you).
The code for making APIs and redirecting after signing ceremony etc. is the same. All you have to do is change the code that was used to obtain the access token (and also you need some configuration changes).
You can find nodeJS example of JWT here - https://github.com/docusign/eg-01-node-jwt
If you want to read more about JWT - https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-jsonwebtoken
I am using the sandbox account and trying to setup an eNotary Profile. Being that its a sandbox area, I would assume that I don't need a valid notary ID to create one.
Can someone help me setup a Notary Profile on my sandbox account?
QA Question Newly Added: Will ALL test users have to go through this same process? or is it just the main account needs it setup. Reason being, we have a client that will be using the system. For our teams, and their teams, we will need accounts to test this.
Added Image
I assume you are talking about IDV which is a special kind of recipient authentication that require them to use an ID before they can sign a document.
This feature is not available in the sandbox normally because there's cost associated with each transaction.
We may be able to assist you on a case-by-case basis if you have a legitimate need to test this functionality in the developer sandbox.
see https://developers.docusign.com/esign-rest-api/guides/concepts/recipient-authentication for more information about recipient authentication.
Setting up eNotary requires some back-end switches to be flipped on your account. Please open a Support Case requesting that be enabled and provide your Demo account ID.
I am trying out Docusign sandbox environment in which I have created an integrator key with appropriate redirect uri
When I request the api:
https://admindemo.docusign.com/oauth/auth?response_type=id_token&scope=open_id&client_id=<integrator-key>&state=custom&redirect_uri=https://webhook.site/1b7aba4c-f96f-41e1-922d-2d8d38392208&admin_consent_scope=impersonation
Docusign does not redirect to the redirect-url, but opens the Docusign admin page.
If I request the URL:
https://account-d.docusign.com/oauth/auth?response_type=id_token&scope=open_id&client_id=<integrator-key>&state=custom&redirect_uri=https://webhook.site/1b7aba4c-f96f-41e1-922d-2d8d38392208&admin_consent_scope=impersonation
Then I get the error:
You are not an organization admin. Please contact your DocuSign Administrator
response_type=id_token is invalid. The response type should be code. Unfortunately, the 'Obtaining Consent' documentation still references this incorrect value.
scope=open_id can only be used if your account is associated with an Organization, and if you are an Organization Administrator. If your account is not under an Organization, you'll need to use the individual consent workflow, which means scope should be signature impersonation and the admin_consent_scope parameter should be removed.
If you would like to create an Organization in the sandbox environment, you will need to open a case with DocuSign Support requesting that functionality be added to your Demo account. To have that enabled in Production, you'll need to contact your Account Manager or the Sales team.
Your question is not so clear -- please update your question if this answer is in the wrong direction.
I think you are trying to implement the oauth authorization code grant flow and are having a problem.
The starting url for DocuSign for the oauth auth code grant flow:
For the developer sandbox environment: https://account-d.docusign.com/oauth/auth
For the production platforms: https://account.docusign.com/oauth/auth
Also, why are you including the admin_consent_scope query parameter?
Hopefully this answer regarding the correct url will help. If so, then ask a NEW question if you run into any future issues.
Developer documentation
We are allowing users who have created their accounts with DocuSign directly to connect to an integration we are providing. As a result, we have no control over the account settings in place for each account created.
We are using the SOAP API and our header is comprised as the following.
r.Headers.Add("X-DocuSign-Authentication",
string.Format("<DocuSignCredentials><Username>{0}</Username><Password>{1}</Password>" +
"<IntegratorKey>{2}</IntegratorKey></DocuSignCredentials>",
Email, Password, IntegratorKey));
On envelope creation everything works, however, on the following calls; RequestRecipientToken, RequestUrlSenderToken, and GetAuthenticationToken we are receiving the following error message, "This User lacks sufficient permissions. Fail to resolve SendOnBehalfOf user".
Do accounts created with DocuSign have the API rights enabled automatically? If not, how do you suggest we instruct them to enable them?
Is there a programmatic change we can make to avoid the issue?
It sounds like the BehalfOfUser may be lacking the proper permissions.
The DocuSign user associated with the element in your request must have the following permissions activated/checked in their DocuSign permission profile. As an DocuSign administrator select Preferences > Users. Find the send on behalf of user. Open their profile and check the permissions associated to them.
1) Within the Sending and Signing section, check 'Send Envelopes'
2) Witin the DocuSign API section, check 'Sequential Signing (API)'
Our implementation was correct but we were passing the wrong variables for that particular user. The header listed in the question can be followed for future implementations.