This is my scenario: I have clients who have their accounts with DocuSign. They want to record the documents information onto our app. Our app would have to call DocuSign to "import" envelope data into our app. We will need account_id to call the Rest API /envelopes, etc...
How do our clients find their account_id to give to our app?
The client need to go to the apps and keys page and find where it says API Account ID and copy the value (There's even a little icon to copy it to your clipboard).
Note that only administrators can access the above page, so your client admin must do this.
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.
We are using the EnvelopeView: CreateSender endpoint on the server side and are authenticated under a service account we have dedicated for this process. Ultimately, we send a URL such as https://demo.docusign.net/Member/StartInSession.aspx?StartConsole=1&t=<GUID>&DocuEnvelope=<ENVELOPEID>&send=1 back to the end user to pick the signers, and populate tags.
All works fantastically, however, we were hoping to make it so the user can only see and populate the information for this single document. Currently, once the user clicks the link they are essentially authenticated as our backend service account and if they open another tab in their browser and go to (https://demo.docusign.net) they can see all documents and even change the password of the account if they wanted.
Is there a way to restrict this in any way? Would the experience be different if purchased an “API” account not tried to use an actual user account on the backend? Yes, we know about OAuth, but we don’t really want to impersonate the sender and prefer to keep a dedicated service account.
An "API" account would give you the same issues as dedicating one of your current users as a "Services Account," so I don't think that's a solution.
Instead, I suggest that you move all of the functionality that's needed upstream into your app. That way you will not need to present the Sender view to your users.
Your app can enable your users to:
choose who the envelope will be sent to
choose/edit the email messages, etc
choose the documents that will be sent
etc
If you have preset templates that include the document tabs/fields for the signers then there is no reason for the sender to deal with the sending screen for picking the tab/field locations on the documents.
This type of app will also give a smoother user experience to your users since they'll stay in your app rather than bouncing over to DocuSign for part of the task.
When using the Docusign API (in my case, via the Sandbox/demo env), in the signing view at the top of the screen it displays the name & company of the user account that was used to authenticate with the API.
However, because this is embedded signing from my app, I would have thought we'd only have one user account - for the app. So I want to change what appears at the top there - the information on the sender of the envelope. Either to be the user account that exists in my app that created the envelope, or just to state what company sent the document.
Are there options on the API to do this? I can't see any reference to anything like this in the envelopeDefinition JSON structure in the REST API docs.
You can use the DocuSign SOBO - Send On Behalf Of Functionality
The Send On Behalf Of feature permits automated sending through the API by one account user on behalf of another account user.
More information here
I am working for the first time with Stripe. I am using stand alone accounts. I have a platform account also. In my web site a number of people with different Stripe accounts will be opening up campaigns for which money can be donated by various donors. Each campaign owner has a separate stripe account and the platform will be charging through the campaign owner's stripe account.
So what it amounts to is the platform account will be charging for a number of campaigns through each campaign owner's Stripe account. My problem is related to web hooks. One point to remember is each campaign has an id associated with it in the database and I am storing the API key of each campaign owner's stripe account and associating it with this id. To get Stripe data from the web hook in the web hook end point I have to set the API key of the connected account with a statement like:
\Stripe\Stripe::setApiKey("api key of stand alone account");
$input = #file_get_contents("php://input");
The trouble with this is there is one web hook end point for a number of Stripe accounts. I cannot hard-code the API key in the above statement. I have to fetch the appropriate API key from my database using the id.
But when Stripe invokes the web hook end point I simply do not have the campaign id with me in order to fetch the appropriate API key and set the API key. Is there any solution around this?
You don't need to store each account's API key. The only information you need to store is the account ID ("acct_..."). With standalone accounts, your integration will receive the account ID in the last step of the OAuth flow, in the stripe_user_id parameter.
You can then issue API requests on behalf of this account by using your own (the platform's) API key, and the Stripe-Account header.
Regarding webhooks specifically, events sent to your server via a "Connect" endpoint will include a user_id field with the account ID. So you can do something like this:
\Stripe\Stripe::setApiKey("PLATFORM_API_KEY");
$input = #file_get_contents("php://input");
$event_json = json_decode($input);
$user_id = $event_json->user_id;
// if you need to send an API request on behalf of this account,
// for example if you want to verify the event by fetching it from
// Stripe, you can use the Stripe-Account header:
$event = \Stripe\Event::retrieve(
$event_json->id,
array("stripe_account" => $user_id)
);
In the DocuSign GUI it shows a number in the top right corner which I presume is the company account ID. If your user is in multiple company accounts then you can switch between these accounts and the number changes. My demo account ID's are 17107 and 1133955.
I cannot find a way to get this ID using the API. I need it because a customer has multiple accounts with the same company name and we need to show the same account ID to them so they can differentiate between the accounts in our GUI like they can in the DocuSign GUI.
With the Credential API I can get the list of accounts for the user but the account ID here is the API account ID which is a GUID, not an integer.
Using a simple Login API call you'll get a list of the user's accounts. Each of the loginAccount objects within that list also contains an accountId parameter.
Please see the documentation regarding the login_information REST API call:
https://www.docusign.com/p/RESTAPIGuide/RESTAPIGuide.htm#REST API References/Login.htm?Highlight=login_information