I am wanting to use the DocuSign REST API to create an envelope for our clients. We are wanting to just create the envelope for our clients to simplify the DocuSign process. Each of our clients will have their own DocuSign account that would be separate from our API Integrator Key Account. I've looked into SOBO and Act-As-User in DocuSign however from what I can tell the user has to be a member of the same account as the API Integrator Account. Would anyone know if you can use another accounts details to create an envelope and how to achieve this?
It sounds like you want to build a partner integration.
SOBO and Act-As-User is for same account authentication.
You would need the user to authenticate with their DocuSign credentials (or someone on the account can use SOBO), combined with your integrator key.
Related
We are trying to build a DocuSign integration (connector) to our application.
Use Case: We have multiple customer and some customer has multiple account. We intend to use Authorization Code Grant/JWT Grant flow to connect customer account to our application. We would be storing access token, refresh token & expiration date for each connection.
Question:
We notice ISV is the recommended route. We would like to understand more on this:
After creation of an ISV/Partner DocuSign account, how do we integrate it with multiple customers' account?
Can we use the same integration key + client secret in ISV/Partner account to retrieve access token an make calls to eSignature API (i.e to send envelopes and signature) for multiple customers' account?
How would the go-live process occur in this scenario?
Other than the above, are there option other than ISV?
ISV simply means that you build integration to be used by many customers, each with their own account. However, an IK can be used with many different accounts, whether you're an ISV or not.
After creation of an ISV/Partner DocuSign account, how do we integrate
it with multiple customers' account?
You create an IK (integration key which is like a clientId) and that can be used to authenticate with any DocuSign account.
Can we use the same integration key + client secret in ISV/Partner
account to retrieve access token an make calls to eSignature API (i.e
to send envelopes and signature) for multiple customers' account?
Yes, this is called Auth Code Grant. Using this method you must interactively log into DocuSign (like providing a password) whenever you use your application.
How would the go-live process occur in this scenario?
Go-live is the same in all cases. You need to make API calls in the developer environment that comply with the rules (at least 20, no polling, no errors) and then you can start the process. You will need a valid production account to complete the process and promote your IK to production to be used by any customer in production.
I'm working on an integration with the DocuSign API. I want the users to log in to my app and then initiate the signing process from there. The users must not have a DocuSign account, they should be able to sign without log in to DocuSign. As I understand the JWT Grant flow is the best choice for this scenario by impersonating a system user and create envelopes and recipient view requests for the users who will sign. Please, correct me if I'm doing this wrong.
Many companies who offer electronic signature services also offer authentication services. For example OTP via email, SMS or some other eID. I would like that if the user could authenticate with DocuSign first before accessing my application. I haven't find a service like that at DocuSign. Is there a way to authenticate users without DocuSign accounts for my application with their service?
You first write:
The users must not have a DocuSign account
You later write:
I would like that if the user could authenticate with DocuSign first
before accessing my application
These two statement conflict. You can only authenticate if you have an account.
However, if what you mean is just get an SMS text there are two features you can use:
Send with SMS - sending the SMS as the means of obtaining a signature from user. User doesn't have to have an account with DocuSign.
SMS authentication - envelope is sent via email, SMS is used as a second factor auth. User doesn't have to have an account with DocuSign.
JWT or Auth Code Grant can either be used for the one user/account that does have the ability to send envelopes from DocuSign. Either one would work.
For context, we are currently developing a DocuSign integration on our DMS web app product. So far what we have done is that the web app's admin (we assume this would be someone like our customer's IT) can set up the integration by entering API Account ID, Integration Key, Secret Key, Access Token & Refresh Token. All these information was taken/generated using a DocuSign admin account. With this, we see that any user using the DMS can send out signing requests (via API) without logging in to their own DocuSign account.
However, we realised this means that all signing requests will be sent using the common DocuSign admin account, i.e. the envelopes originate from the admin account and all signed documents also stored in the DocuSign admin account. This is not what we want as the DocuSign admin can see confidential signed documents.
I'm quite confused and would like to seek advise on how should we go about this? Ideally, it is that User A of the DMS can associate his DocuSign account with his DMS account. So that when User A sends out the signing request from our DMS, the signer receives the email from DocuSign showing it is from that user instead of the common admin account.
Also, it looks like the go-live process would have to take place for each customer that is using our DMS? Does it mean like each customer need to have their DocuSign developer account so that the integration key can get promoted to production environment? Or am I in the wrong direction & should look at Partner Integration as ISV?
If your DMS system is a SAAS system, then you can have 1 integration key (client id) for your integration with DocuSign. In other words, your individual customers would NOT have their own integration keys, secrets, etc.
One integration key is the best, if your application's architecture can support it. To do so, you'll want to have one or just a few Redirect URIs to enable your users (who also have DocuSign accounts) to authenticate with DocuSign.
Your app then stores the resulting access token, refresh token, and expiration date for each of your users who have authenticated with DocuSign.
This way, as you say, when your users send out an envelope for signing, it will belong to their own DocuSign account, and will show them as the sender.
When your customer wants to send via DocuSign, your app checks the expiration date for the person's access token. If the access token has expired, then use the refresh token to get a new access token and a new refresh token.
The refresh token is stored in your app's non-volatile storage (encrypted is best) so you can use it days or weeks later for the user. That way they don't have to re-authenticate with DocuSign. For this case, use scopes signature%20extended
For the account_id info, use the user's default account and enable them to switch to another account if they wish.
More information:
Getting started for ISVs
API integration guidelines
I am a developer who is creating DocuSign integration. I want to authenticate other production account using this integration. I have worked with other third party integration(like salesforce, mailchimp, etc.), usually it works fine for other integrations. I just want to confirm that it is the same case here in docusign.
About pricing, If I push my integration to production and authenticate other DocuSign account (if possible) using that integration, then when ever other production account uses this integration to send envelope requests for signing then who will get charged for it? my account or authenticated user's account?
Yes, you can authenticate other DocuSign users' accounts and can send envelopes for signature on behalf of them, DocuSign call this type of Integration a Partner App Integration, where you application will be a Partner App and your users will authenticate your App to call DocuSign API on their behalf. You can check Service Integration of how to accomplish this, you need to check User Consent section in your scenario. Now answer to your 2nd qs, Authenticate User's account will be charged for any envelope sent from the authenticated User's account.
I am wanting to use the DocuSign REST API to create an envelope for our clients. We are wanting to just create the envelope for our clients to simplify the DocuSign process. Each of our clients will have their own DocuSign account that would be separate from our API Integrator Key Account and they will share the API integrator account. How can I achieve this.
Docusign supports various authentication options to support multiple scenarios.
Based on your problem statement it looks like you are building a User Application.
See the Documentation to build user applications over the DocuSign api.