Skip to main content
ConfigView reads your Docusign account through Docusign’s eSignature REST API, Admin API and (if you have it) Monitor API. It signs in with an integration key that you create and own, using Docusign’s JWT grant to act as one Docusign admin user. You will end up with 3 secrets in ConfigView (DOCUSIGN_INTEGRATION_KEY, DOCUSIGN_USER_ID, DOCUSIGN_PRIVATE_KEY) when setup is complete, plus 2 optional ones.
Scope of this integration today. ConfigView reads who has a Docusign seat and with what permission profile, who is an account or organization administrator, when people last logged in, which groups exist and who is in the Administrators group, the Connect webhooks that push envelope events (and possibly signed documents) to other systems, your claimed domains and single sign-on setup, and the Docusign Monitor security event stream. ConfigView never reads envelopes, documents, templates, recipients or anything anyone signed, and never creates or changes anything.
Why you create the key yourself. Docusign only lets an integration key talk to a production account after it passes a self-serve Go-Live check. Creating the key in your own Docusign developer account and promoting it to your own production account keeps the key, its private key and its consent entirely in your hands. ConfigView is not a Docusign partner app and never sees a key it didn’t get from you.

​
Step 1: Open the Docusign page in ConfigView

Open ConfigView in a second browser tab and leave it open: https://{companyname}.configview.com/admin/integrations/docusign

​
Step 2: Create a dedicated Docusign API user

The integration acts as one Docusign user, so give it a user nobody will leave or rename:
  1. In your production Docusign account, open Settings → Users → Add user. Use a shared address such as docusign-api@yourcompany.com
  2. Give it the DS Admin permission profile. Without account admin the users list shows only that user, and Connect webhooks are refused
  3. Optional but recommended: in Docusign Admin → Organization → Administrators, make the same user an Organization Administrator (a Security Reports Administrator role is enough if your organization has it). This unlocks last-login dates, organization users, claimed domains, single sign-on and Monitor events. Organizations are part of Docusign Admin and need the account to be linked to one
  4. Sign in as that user once and accept the activation email

​
Step 3: Create the integration key in a developer account

  1. Go to developers.docusign.com and create a free developer account (or sign in to one your company already has)
  2. In the developer account open Admin → Apps and Keys → Add App and Integration Key. Name it ConfigView
  3. Choose Private custom integration. Leave User application at the default
  4. Under Authentication, select Authorization Code Grant and leave Does your application store the client secret at No. You don’t need a secret key
  5. Under Service Integration, click Generate RSA. Copy the private key. You’ll use this one only for the developer environment
  6. Under Additional settings → Redirect URIs, add https://developers.docusign.com/platform/auth/consent
  7. Save. Copy the Integration Key (a GUID) and, from the top of Apps and Keys, your developer User ID

​
Step 4: Make the 20 test calls Go-Live needs

Docusign checks that the key’s 20 most recent API calls in the developer environment succeeded before it lets you promote the key. ConfigView can make them for you:
  1. In ConfigView, set DOCUSIGN_ENVIRONMENT to demo, and paste the developer Integration Key, developer User ID and the developer private key into DOCUSIGN_INTEGRATION_KEY, DOCUSIGN_USER_ID and DOCUSIGN_PRIVATE_KEY
  2. Grant consent as the developer user. Open this link in a browser, with your integration key in place of YOUR_KEY, sign in and click Allow access:
  1. Click Connect, then Run now on the Accounts, Users, Permission Profiles, Groups and Group Members collectors two or three times. Each run makes a handful of calls. Sign-in and userinfo calls don’t count toward the 20
  2. In the developer account, check Apps and Keys → API Dashboard shows at least 20 recent successful calls

​
Step 5: Go-Live and promote the key to production

  1. In the developer account, open Apps and Keys, open the ConfigView key’s Actions menu and choose Start Go-Live Review. The review is automatic and usually passes within minutes
  2. When the status reads Review Passed, click Select Account, sign in to your production account as an admin in the pop-up (allow pop-ups first), and pick the production account. Trial accounts can’t receive a promoted key
  3. Sign in to your production account and open Settings → Apps and Keys. The ConfigView key is listed there with the same Integration Key
  4. Open it, and under Service Integration click Generate RSA. RSA keys don’t carry over from the developer environment
  5. Copy the new private key, and the User ID of the API user from Step 2 (shown on its user record, or at the top of Apps and Keys when signed in as that user)

​
Step 6: Point ConfigView at production

  1. In ConfigView, delete DOCUSIGN_ENVIRONMENT (or set it to production)
  2. Paste the production values: DOCUSIGN_INTEGRATION_KEY (unchanged), DOCUSIGN_USER_ID (the API user’s production User ID) and DOCUSIGN_PRIVATE_KEY (the production RSA private key, including the -----BEGIN RSA PRIVATE KEY----- and -----END RSA PRIVATE KEY----- lines)
  3. Optional: set DOCUSIGN_ACCOUNT_ID to one account’s API Account ID to collect only that account. Leave it unset to collect every account the API user belongs to
  4. Grant consent as the API user. Sign in to Docusign as docusign-api@yourcompany.com, then open this link with your key in place of YOUR_KEY and click Allow access:
The page you land on afterwards can show an error. That’s expected: the consent is recorded before the redirect. If your organization uses Docusign Access Management with a claimed email domain, an organization administrator can grant this consent for everyone under Docusign Admin → Connected Apps instead.

​
Step 7: Connect and verify

  1. Click Connect (or Run now if the collectors already exist). ConfigView creates its tables and schedules every collector at your default run time:
  1. Click Verify now. The health check confirms the secrets, the RSA key, the token, the accounts and one users call, then reports each optional part as ok or skipped.
If a check fails:
  • consent_required. The API user hasn’t granted consent in this environment. Open the consent link from Step 6 while signed in as that user.
  • issuer_not_found. The integration key doesn’t exist in production yet. Finish Step 5 and promote it.
  • no_valid_keys_or_signatures. The private key isn’t one generated on this key in this environment. Generate a new RSA key in the production account and paste it.
  • invalid_grant. Usually DOCUSIGN_USER_ID is from the other environment, or is an email address instead of the GUID.
  • Admin API skipped. Either the consent covered only signature impersonation (run the Step 6 link again, it lists the organization scopes) or the API user isn’t an organization administrator.
  • Monitor skipped. Your plan doesn’t include Docusign Monitor. Nothing to fix.

​
Data Tables

Once the scripts run, these tables are created in your database. Each includes a run_at column. Snapshot tables keep only the newest run.

​
Things worth knowing

Last login has two sources. Docusign marks the eSignature lastLogin field as deprecated, so docusign_users.last_login can be empty. When the API user is an organization administrator, docusign_org_user_profiles.last_login comes from Docusign Admin and is the one to trust. The catalog questions use it first. User Profiles refresh in rotation. Docusign has no bulk last-login export over the API, so ConfigView reads one profile per person and refreshes up to 400 a run (DOCUSIGN_PROFILE_LOOKUPS_PER_RUN), never-seen and stalest first. A 1,000-person organization is fully refreshed every three runs. run_at on that table is when each person’s row was last refreshed. Monitor events are a permanent ledger. Docusign Monitor keeps events for a limited window. ConfigView stores each event once and never prunes, so history outlives Docusign’s retention. The first run starts at the earliest event Monitor still has. API calls are shared with your other integrations. Docusign allows 3,000 calls an hour per account across every integration. ConfigView stops a run once fewer than 1,000 remain in the hour, so your own integrations always keep most of it. integrator_key on Monitor events names apps by key. It’s the integration key that made an API call, a GUID. Match it against Settings → Apps and Keys or your vendors’ documentation to see which app it is.

​
What isn’t collected

  • Envelopes, documents, templates, recipients, form fields, signatures, attachments, and anything anyone signed or sent
  • Connect webhook URLs beyond the host, basic-auth usernames and passwords, OAuth client secrets and HMAC keys
  • Monitor event data beyond its ID fields (envelope subjects and recipient names are dropped)
  • Users’ home and work addresses, signature and initials images, and activation codes
  • The text verification token of claimed domains