We are using DocuSign API via demo account for signatures. We are using Authorization Code Grant workflow and are obtaining authorizations in our demo workflow. So real access tokens are being used.
But no API calls are being shown in our demo account API Dashboard.
But I can see via our monitoring tool we are hitting DocuSign. Plus the flow of the integration is all working properly.
Why are the calls not showing up? This is affecting our ability to proceed with app review process.
Notes
The model we're using is ISV
We use Authorization Code Grant workflow
We obtain user authorization for users outside of our account since we are an ISV
My question is similar to this one but we are using real access tokens.
The information in the dashboard may be outdate by 10-20 minutes as it takes some time for the process to get the API requests to the dashboard.
Please allow for a few minutes of delay and check the dashboard a bit later if you have new API calls you're trying to view in the dashboard.
Also, for ISVs, the portal only shows your own account. You must make the API calls from your own account that was used to create the IK. If you use a different account - it would not show in the developer dashboard.
Related
First of all, I apologize for eventual noob questions, we are very new to the DocuSign API and are currently trying to wrap our heads around which is the most correct way of accessing the API.
I will start with an overview of our use case. We recently purchased a DocuSign prod. Account with an Organization enabled.
We have a Partner which uses a CMS Tooling which integrates with said DocuSign Account. This Tool allows for the Backoffice to create envelopes with documents inside and a url which leads to the signin ceremony through the Templates that we create inside the DocuSign Account. This url is afterwards send to the customer for them to sign the documents in the envelope. This Part is working and is currently being used.
Now what we want to achieve on our side, we have a nextJS web-app which allows the same customers (Which are the receivers of the created envelopes in the step above, same e-mail in both steps) to sign-in our web-app. We want to show the customer in a dashboard, if there are envelopes for him open that he can sign and if this is the case we want to show him the url which leads to the signin ceremony.
We were able to see that as soon as an envelope for a certain User is created through the CMS Tooling, we can see that envelope in our DocuSign Prod Account.
Now our thought process was, to show our customer his open envelopes, we just fetch all open envelopes in our DocuSign Account which match the customers E-Mail.
Is there anything wrong with this process or are we overlooking something?
And if it is okay to proceed this way which of the OAuth Flows is the correct one to use for this case?
From my understanding, the JWT Flow seems like the most reasonable one? Since the Customers that need to sign the documents, will not have any DocuSign accounts.
What have you tried to solve the issue?
We tried using the direct API Access, which worked when set up correctly but since we didn't have a OAuth Flow in place the Access token is only valid for restricted amount of time obviously and has to be refreshed. Hence we have to think first about how to grant access correctly
I would love to hear, what the right approach would be to achieve our desired result.
Once again Apologies for this kind of question, just trying to have a better understanding before we start building :)
Best regards!
According to the use case you mentioned using JWT Grant is fine as users of your integration will use a single system account to log in, you should use JWT Grant.
I would recommend going with the below link to know more regards different use cases and check the knowledge
https://developers.docusign.com/platform/auth/choose/
https://developers.docusign.com/platform/auth/oauth2-requirements-migration/
This is my first time posting so apologies if I don't explain things clearly.
I've created a Custom Connector within Power Apps that does an API call to my DocuSign Account. The API call I am currently leveraging is to create DocuSign Envelopes:
/restapi/v2.1/accounts/{accountId}/envelopes
Link to DocuSign API Library: https://developers.docusign.com/docs/esign-rest-api/reference/envelopes/envelopes/create/?explorer=true
My issue is that I do not know how create Envelopes on behalf of other DocuSign Users while using the API call within my Connector. Since the Custom Connector required me to log into my DocuSign Account, every time I use the Connector the Envelope generated from the API call gets associated to me (I am able to see it within "Drafts" when I log into my DocuSign).
Sorry if this is a bit confusing. My end goal is to use my Custom Connector and its API calls within a Canvas App. However, I want the Envelopes created not to always be associated to my DocuSign account especially if the Canvas App is used by other End Users.
Any help would be much appreciated!
Thanks!
Screenshot of Test call:
Request
Screenshot of Test Call: Response
Screenshot of Envelope within DocuSign Account: Snippet
This is Yara from DocuSign Developer Support.
Since you want to create envelopes on behalf of other DocuSign Users while still using the API call within your connector, you can use the Send On Behalf Of Functionality (SOBO). This functionality allows a single user in an account to authenticate for other members of the account and send fully defined envelopes on their behalf.
Here's a detailed guide on the SOBO functionality: https://developers.docusign.com/docs/esign-soap-api/esign101/auth/send-on-behalf-of/
I have a scenario and for what I believe is a common scenario for many websites :)
I have a website that uses Nextjs for frontend and asp.net core as backend. It uses Azure ADB2C for managing its users.
Now When the user is registering, I will collect some basic details which would be done through the userflows in Azure ADB2C.
Before the user creation is completed, I want to come back to my website to allow the user to select the subscription option and let the user click on subscribe button.
Based on this, there will be a call to third party payment gateway service like stripe/RazorPay... which takes over and allows the user to complete payment.
The payment gateway would send the success/failure notification back to my website which I will use to decide to proceed to complete user creation or discard the creation process.
Using ADB2C seems to be quite a big task with custom policies :)
Need help/suggestions/links
Is it possible for us to come back to my website from ADB2C in between the registering process? I see an option using Custom policies with REST call, but will that really help? This is not just a REST call.
OR
Is it possible for me to let the user first choose the subscription option and then pass on that data to the ADB2C userflow. Not sure if we can pass data that way to the signup userflow. if you have any link that does that please share it with me.
The second option seems to be more easy if I have a way to send some input to the signup flow.
With custom policies, it is possible to extend the signup screen by adding subscription options.
Then call a REST API to the payment gateway.
This will return to B2C.
If all is good, write the user data to B2C.
If not, display an error message and discard the data.
I am trying to integrate our web app with DocuSign. We expect our web app customers will authenticate and grant consent to our app to make API calls on behalf of their DocuSign accounts. Then our app will create envelopes (using access tokens to customer DocuSign accounts) and allow our app users to sign them using embedded signing.
We've built a prototype using demo account and everything works like a charm.
The only thing what is still unclear for me is how it is supposed to work after going live.
Am I right that our customer will be charged each envelop sending, since our integration makes call on behalf of their account?
Is it enough for our customer to pay for Standard eSignature Plan to make embedded signing work, or they should choose Enhanced Plans (the one where API feature is listed)
Should our account plan (which holds Integration Key) be at least Advanced Developer to support embedded signing?
Could anyone advise on the matter. Thanks!
Am I right that our customer will be charged each envelope sending, since our integration makes call on behalf of their account?
A. Yes, you're right. If your customer logins in to DocuSign using their own DocuSign user account, then their DocuSign account is charged. Your own DocuSign account is not involved, at all, in this scenario. Your client id (integration key) can be used by any DocuSign account user with their own account, once they grant consent to it.
Is it enough for our customer to pay for Standard eSignature Plan to make embedded signing work, or they should choose Enhanced Plans (the one where API feature is listed)
A. I don't believe that the standard eSignature plan includes support for embedded signing.
Should our account plan (which holds Integration Key) be at least Advanced Developer to support embedded signing?
A. Either Advanced Developer or a "regular" eSig account that supports embedded signing. This is for your testing purposes. If you use a regular account that supports embedded signing then your other company groups can share the account for use in sending out agreements for signature.
Also
Please sign up as an ISV with DocuSign via https://partners.docusign.com
(no charge.) Being a registered partner provides you with additional information and enables you to use the partner use license to sell your app to DocuSign customers.
Pro-tip: use your developer account to automatically test your app. Preferably once a day. New releases are first launched on the developer system about a week before production. DocuSign has thousands of tests to guard against regression bugs. But it is possible for a bug to slip through. If you detect any issues on the developer system then DocuSign will typically stop the production deployment to fix the issue.
Added
Re error message when a feature is not enabled: see this question.
Re which plans include the embedded signing feature: sorry, I don't have that information.
We are from MCAS Team from Microsoft, India. We have specific Docusign Integration use case which needs your expert suggestion.
MCAS(Microsoft Cloud App Security Team) one liner – MCAS is a single/ common platform provided to Microsoft customers for monitoring all their cloud applications used in their organization helping the customer admin to monitor & track malicious/ unusual user behavior and configure necessary alerts & actions.
MCAS Documentation for more details : https://learn.microsoft.com/en-us/cloud-app-security/
Our Use case: Integrate the Docusign API - https://developers.docusign.com/docs/admin-api/reference/users/users/getusers/
and
https://developers.docusign.com/docs/monitor-api/reference/monitor/dataset/getstream/
Queries:
How to avoid the DocuSign App integration key Go-Live process for every MCAS customer(tenant)?
How to get a common higher rate limit benchmark for all the Microsoft MCAS customer(tenant) without explicit action by every MCAS tenant
How to get the Events of a organization in Global App Context. As on date, Events API is Integration key level but how to get events at Organization level
How to get the users of an organization. Current Admin API only supports by passing either of AccountId (API Account Id) or Reserve Domain Id or User emailid
User Profile Admin API expects email Id as input. This is returning array of users. How to get the User by User Id?
User roles are not returned in getUsers Admin API. Why?
Any API which would get the to get the user details by Id?
Every IK (Integration Key) must be approved to go live so that it can be used in production, but you can use the same IK for multiple things if they are related (back-end and front-end of app for example).
Work with your DocuSign rep (support/sales) to help increase your rate limit if there's a legit need to do so.
See how to get Monitoring Events using the DocuSign Monitor API.
The DocuSign Admin API can be used to get all the users in an
organization.
REST eSignature API can be used to get a user by userID (GET
/restapi/v2.1/accounts/{accountId}/users/{userId})
User groups and permission profiles are returned by Admin API or eSignature API. Roles are related to templates, so the terminology may be the issue here.
For users of eSignature you can use https://developers.docusign.com/docs/esign-rest-api/reference/users/users/get/