I am running into conflicts using Docusign connect with multiple environments.
My Sandbox account is being used by Staging, Review apps & Dev environments. Docusign Connect is sending out envelope-events to environments that have not created the envelope which is causing lots of confusion.
This must be a common issue - is there a recommended way of handling it?
The only work-around I can think of is to add an sending_environment custom field with each envelope and then filter out the envelope-events when they are sent to each environment.
Thanks
Yes, using custom fields is a good approach.
I assume when you say "multiple environments" you mean your company/app/IT etc. not DocuSign's.
If it was DocuSign's (demo/sandbox vs. production) you could tell based on many things, account number, envelope ID, URL etc.
in any event, putting a text field that you can retrieve on the other end is a good way to handle this.
What I think you can also do, is have a different DocuSign configuration for each of your environments, such that they use different URLs for the callback from DocuSign. That approach may be more or less work than the other approach. Your call.
The solution we have gone for:
Each Dev sets up their own 'user' account (invited via the docusign account dashboard)
Devs use their credentials locally
Staging & Review apps use the default sandbox docusign user account
Production uses the default production docusign user account
Once this is done, we set up a permissions check on each envelope event that arrives, ensuring the user <Email> field matches that of the current environment
<?xml version="1.0" encoding="utf-8"?>
<DocuSignEnvelopeInformation>
<EnvelopeStatus>
<TimeGenerated>2020-05-18T12:00:00</TimeGenerated>
<EnvelopeID>abcdef</EnvelopeID>
<Email>me#gmail.com</Email>
</EnvelopeStatus>
</DocuSignEnvelopeInformation>
This ensures Dev environments don't conflict with staging & review apps.
Next we need a way of distinguishing Staging and each Review app. For this we add a <CustomField> to each envelope that we create, and in Staging & Review app environments, add an additional check for that custom field to filter out any envelopes that were not created in the current environment.
Related
So I have been using docusign developer account for performing in-person and remote signing using docusign APIs. I am interesting in knowing 2 things:
The developer account (with the base url account-d.docusign.com) seems to be working fine for me. Why can't I use it for production as well. What difference/advantage does the paid account(with API access) has? What changes exactly when the integration app that I am using for docusigning goes live from "demo", other than the base url (i.e., account.docusign.com)?
When I login to my account, and go to Settings > Integrations > Apps & Keys, I can see a value "baseUrl" under "API Username" and "API Account ID", this value is either "https://na3.docusign.net" or "https://demo.docusign.net". However, when I use either of these values in my code to perform in-person or remote signing, it gives error. I have to use url account-d.docusign.com, then the API calls work correctly. What is the use of baseUrl mentioned in the portal then? Does it change when the integration app goes live? In our old app we just changed the url in code from account-d.docusign.com to just account.docusign.com when app went live and it worked.
Production accounts are the only ones you can use for "real" i.e. valid signatures for legal purposes. Developer account (demo) is for developing, testing, showing what can be done to customers etc. You need to follow the Go-Live process to enable your integration in production.
the baseURL is for API calls, not for authentication. And like you indicated, it's different in each env. If your code already handles this - you don't need to worry about it, but this is not the URL for the web app, rather the URL to make API calls.
I am using the sandbox account and trying to setup an eNotary Profile. Being that its a sandbox area, I would assume that I don't need a valid notary ID to create one.
Can someone help me setup a Notary Profile on my sandbox account?
QA Question Newly Added: Will ALL test users have to go through this same process? or is it just the main account needs it setup. Reason being, we have a client that will be using the system. For our teams, and their teams, we will need accounts to test this.
Added Image
I assume you are talking about IDV which is a special kind of recipient authentication that require them to use an ID before they can sign a document.
This feature is not available in the sandbox normally because there's cost associated with each transaction.
We may be able to assist you on a case-by-case basis if you have a legitimate need to test this functionality in the developer sandbox.
see https://developers.docusign.com/esign-rest-api/guides/concepts/recipient-authentication for more information about recipient authentication.
Setting up eNotary requires some back-end switches to be flipped on your account. Please open a Support Case requesting that be enabled and provide your Demo account ID.
I want to publish my API, but I want to limit so users can only execute in sandbox environment (I want to limit production to specific user/customers with specific agreement).
This is a basic functionality in other API managers, but I don't find how to do in WSO2.
I have found this article in Medium, and also noticed that when I create an aplication, a couple of new roles are created (Application/user_application_SANDBOX and Application/user_application_PRODUCTION), but I don't find how to use them.
Deep dive in doc doesn't helped me.
Option 1:
You can use application registration workflow to control key generation for production and sandbox, by sending it through an approval process.
If you want to automate it based on a property or something, you can write a custom workflow extension.
However, this is applied to applications but not to APIs. That means if you allow generating prod keys for an application, all APIs, that the application has subscribed to, are accessible with prod keys.
Option2:
If you want to do this in API level, you can write a custom mediation sequence. Within the custom sequence, you can read the key type (i.e. production or sandbox), subscriber, enduser (if required) etc. and decide whether you want to allow the request or not.
Is the baseUrl value returned per user or can it be used by all future users of the same account? I want to cache this value and as far as I can tell this is actually an account setting even though it's only retrieved after a user specific login. Any chance two users of the same account could have a different baseUrl? Just want to know at what level i really need to cache this.
thanks,
-mike
It is Per Account
Is the baseUrl value returned per user or can it be used by all future
users of the same account?
restapi/v{#}/login_information
This call will give you back the list of accounts that the username/password has access to. Along with the list of accounts, you'll receive the baseUrl for that account.
baseUrl defines two things:
The server that the account resides on
The account number
If there is a specific account that you're going to add users to, the baseUrl will be the same for future users of that account.
If you do not have multiple accounts logging into your application.
You can cache the information from this call so you don't have it in every workflow. It is mostly used for setting up new workflows and moving between Demo and Production.
If you do have multiple accounts logging into your application.
I would advise that you call this information at the start of your workflow. It'll ensure that you're calling the correct account for that user.
One thing to keep in mind, that 1 set of username / password can have access to multiple accounts. So you may receive more than 1 array as a response, your application should handle this accordingly.
DocuSign's LoginInformation method enables the implementation to provide dynamic re-direction of the clients at a macro-level.
Currently, or in the future, DocuSign might use the feature for a number of different reasons that I can imagine.
Using an undocumented "feature" (properties of the baseURL result) can result in a brittle client that may fail in the future. Be careful of the siren-song of pre-mature optimization.
The baseURL value changes only when you move from different environments (i.e: DEMO vs PROD). I would encourage you to store/cache it yes. Keep in mind when your application is ready for PROD, you will want to get the baseURL for PROD and store/use that appropriately.
I am writing an application that uses Docusign and I’m trying to figure out the best way to manage my Docusign account in general.
Here is the use case:
1) My software uses custom Docusign templates and tabs and uses the Docusign API to accomplish populating the templates, tabs, and generating envelopes
2) The user will have to provide their own Docusign account to use my software
Questions:
1) How do I get the custom templates loaded into their Docusign account?
Can templates be shared between totally disparate Docusign accounts?
Other options I think might work are an export or import of the templates (but that is clunky).
Maybe I can use the API to upload the templates as well???
2) Who’s Docusign Integrator Key do I use?
Do they need to generate one from their Docusign account and I use that one from my software? Or do I ALWAYS use my developer integrator key???
3) Who’s API username and password do I use to log in via the API?
I assume theirs, but I’m not a fan of needing to save a bunch of Docusign passwords in my database.
Any other options for setting this up the right way???
Thanks everyone!
For future inquires, include if you're using REST or SOAP.
Here are the answers to the questions that you have above.
1) How do I get the custom templates loaded into their Docusign account?
Can templates be shared between totally disparate Docusign accounts?
Other options I think might work are an export or import of the templates (but that is clunky).
Maybe I can use the API to upload the templates as well???
Templates can only be shared within users on the same account. There isn't a way to upload a template via the API either. You can use composite templates for a standardized template across multiple accounts (depending on SOAP/REST, the coding changes here)
2) Who’s Docusign Integrator Key do I use?
Do they need to generate one from their Docusign account and I use that one from my software? Or do I ALWAYS use my developer integrator key???
Your application will always use your Integrator Key, which will only work in Demo until you go through the Certification to get the Integrator Key promoted to production.
More info on that process here: https://www.docusign.com/developer-center/go-live/certification
3) Who’s API username and password do I use to log in via the API?
I assume theirs, but I’m not a fan of needing to save a bunch of Docusign passwords in my database.
Any other options for setting this up the right way???
You will need specific permissions enabled on a user and on an account to make API calls successfully. Most integration's use a system user to login and make these calls. If you're working within multiple accounts that you do not have administration over, you will end up running into permission errors.
It sounds like you're wanting to setup a Partner integration, which does differ a little from a standard integration.