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/
Related
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.
When using ‘https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature&client_id=92e53xxx9-4xxxxxxxxxxxxxxxx2f893&redirect_uri=xxxxx’, after logging in to Docusign Account and obtaining AccessToken, calling CreateEnvelopes API returns the error'The specified User is not a member of the specified Account.'
[add User][1]
[1]: https://i.stack.imgur.com/jEWFv.png
I found that this User must be added in the User module before it can be used. For users who already have a Docusign account and they have paid for it, do they have to invite it? If an invitation is also required, how is the fee calculated?
What we need now is that users already have their own Docusign accounts and have paid for them. We help with the integration. The expenses are also directly deducted from their own Docusign accounts.
Many potential issues here.
First, When you call CreateEnvelopes API you need to provide an accountId (GUID) in the URL. That has to match the right account that you plan to use.
Second, you have account-d.docusign.com which is the developer env, but you are talking about
users who already have a Docusign account and they have paid for it
That suggests a production account, which is account.docusign.com
You should also check the baseURI that you make API calls to, is that demo.docusign.net or something in production?
Generally speaking, a user must be a member of the account where you make API calls and the user is determined based on the authentication. However, users can be members of more than one account, so that's another potential wrinkle here.
If an invitation is also required, how is the fee calculated?
Odd question for a developer forum, but yes, some accounts in production charge by seats, which means that if you have more users - you may get charged more, you will have to contact DocuSign Sales for details on your specific account plan and pricing.
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.
I have a system in which I am integrating the DocuSign API.
Inside my system my client can send a document to the emails that it defined.
I have a DocuSign account with the Integration Key enabled on my system, how do I register within my account the subaccounts for each of my clients to send their contracts to their clients using the API?
I have already tested the entire Docusign API, I just can not find how to register sub-accounts to send on behalf of each client of mine!
Your question is not too clear. Hopefully this will be of help:
DocuSign does not have "subaccounts."
DocuSign has organizations (which group together an organization's or company's accounts).
Customers often have multiple accounts, with or without the organization capability. Accounts have account-wide settings. So it is common that the HR and Finance departments will have separate accounts, with different settings.
Accounts have one or more members (users). An individual can be a member of more than one account.
An Integration Key (also called a client_id) identifies an application.
An Integration Key (and its app) can be used by any user on any account. The user must give permission for the application to act on his/her behalf.
DocuSign has a developer sandbox (called demo) and multiple production systems (Europe, North America 1, 2, 3, etc). The Integration Keys in demo are entirely separate from those in the production systems.
The "Go-live" process is used to copy an Integration Key from demo to the production systems.
We're planning a web service based on recurring monthly payments.
The site would have similar user accounts as Netflix or Spotify. The site would have an account section were the user can manage the billing and other details.
I've looked into different payment gateway provides, but I'm still wondering how to implement the user account as a part of the main site and how to combine that to the billing system.
First some information:
The site would first have just one monthly plan xx$/month
Credit cards need to be accepted
We're based in EU
We don't want to use PayPal
The user account section would contain:
User profile (name, email, etc.)
Website options (features on / off)
Subscription & billing management (edit credit card, current period, cancel, etc)
Questions:
How to combine the basic user accounts on my site with the billing system provider?
What information should I store in my own database?
Should I use a 3rd party user account management software on top of a payment gateway provider?
If so, which one would work similar to Spotify's account management?
How to setup the first sign up flow where user enters CC information?
Thank you for the ideas!
This is relatively easy to do using Laravel (a php framework) and a package called cashier. This package uses a payment service called Stripe which allows you to create recurring payments. There is even a tutorial on how to do it on Laracast.