Im working on PAT Lifecycle Management API to get details of PATs in an Azure Devops Organization and send a remainder mail to team on expiring PATs
Im able to get the PAT details but how can I automate sending a notification for the team before a month or week of it's expiry
Based on this document, Users receive two notifications during the lifetime of a PAT - one upon creation and the other seven days before the expiration.
Currently there is no built-in way to send notification email to team on expiring PATs. For this, you may access this URL: https://aka.ms/AzDevOpsIdeas to submit any comments and proposals for future releases and implementations.
By the way, if you are using this API to list the PATs in an organization, please be noted that you will only get the details of the PATs that created by the user who generated the bearer token for authentication to call the API, rather than all the PATs of all users in this organization.
Related
I am following Intuit's oAuth authentication guide in order to log users in through Quickbooks and get access/refresh tokens in order to make API calls. We make API calls in node through the node-quickbooks SDK.
I can successfully log users in through Quickbooks and exchange codes I receive for access and refresh tokens, and I can even make API calls to create invoices successfully.
The problem is, even when I use the tokens of the user I've authenticated to make API calls, the invoice is created in our Quickbooks company instead of theirs.
Is it possible to create invoices in the Quickbooks account of the other user? If not, what's the point of getting access and refresh tokens for them in the first place? For what it's worth, this is all being done in the Quickbooks developer sandbox (but with two separate accounts).
I'm quite confused as to what the methodology is supposed to be here, and any guidance would be very much appreciated -- or even just a reassurance that this is possible.
Thank you!
The QuickBooks instance that's acted on is determined by the Realm ID parameter. The Realm ID is captured when a QuickBooks Online account is selected during the authorization flow.
If we could call your Quickbooks company "Company A" and the one you're trying to create invoices in "Company B", I'd say it sounds like Company A's Realm ID is being logged and passed in subsequent requests instead of Company B's. This could be caused by things by hard-coding Company A's Realm ID and using that for the create invoices requests, selecting the wrong account during the authorization process, or something trickier like a bug in the SDK you're using.
I'd start by getting Company A and B's Company ID, which is what Intuit calls the Realm ID when you access it from the UI. You can do that while logged into a sandbox or production account by pressing Ctrl + Alt + ? in Windows or Control + Option + ? in macOS. Then you can verify the correct Realm ID is being used in the create invoice requests.
If the requests are using the value captured during authentication (as they should be), then you can —in the SDK code— log the Realm ID that's being captured during authorization and verify it's the right one for the company you selected during the OAuth flow.
Using the REST API for remote signing and it's been working great for about a year now.
We have a user of our system that wants to send documents for e-signature, and I'd like to limit their access to their own documents, let them get the notifications of document completion, etc.
I know I can create additional users in the admin section but I'm not sure of where to look from there. Is any of the rest possible?
Yes, add the person as a regular (not admin) sender in your DocuSign account. They'll only be able to see envelopes (transactions) that they sent.
They can also see envelopes that were explicitly shared with them by another sender
Added: authenticate as a different person
Your API application sends envelopes by using the credentials of an account member. If this is a non-person such as "finance#yourCompany.com" then we call that a "system user."
Your question was how to send envelopes from a sender who is not an administrator. The answer is to authenticate to the DocuSign API as that person. This can be done with the OAuth JWT or Authorize Code grant flows.
Ask a new question if you have more questions on how to do this.
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/
I had created one DocuSign trial account but here i need to Use the DocuSign API then i created developer account(Sandbox) with the same credentials that i used while creating a DocuSign trial account.
Here i am having an issue .. I have tool in which i am using that API to create and send the envelope but to get the envelope status i want to use the pipeline to get the latest envelope status.
But the pipeline does not connect with the developer account and it can connect with the normal account.
Can you please let me know is there any way where we can communicate 2 accounts or can we call API with the normal trial account?
Sandbox accounts are in the Demo environment, Trial accounts are in the Production environment. Those two systems are effectively air-gapped and cannot communicate.
In order to make API calls against your trial account, you will need to authenticate as a member of that trial account.
We are using OAuth2 to authenticate the users to DocuSign, after the authentication we use the AccountsApi call to get account information to get the account id of the logged in user. This is in the form of "ecsddfbfa5-13d2-4e8e-c49e-a214r166b987", so we save this login information. Now, when we receive the webhook notification on completion of an envelope, we get the account id as part of the custom fields and this is in the form of "7657898" (numeric). The issue is that we can't map the notifications with the user that initiated the signing.
One way of ensuring the account ID that you get from DS event notification is the same as the one that was used to login is to do a GET /v2/accounts/{numericAccountId} and compare its response.accountIdGuid with the one you got at login-time (most-likely from GET /oauth/userinfo).
See https://docs.docusign.com/esign/restapi/Accounts/Accounts/get/