> ## Documentation Index
> Fetch the complete documentation index at: https://support.configview.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Docusign setup

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](https://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**:

```
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=YOUR_KEY&redirect_uri=https://developers.docusign.com/platform/auth/consent
```

3. 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
4. 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**:

```
https://account.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation%20organization_read%20user_read%20account_read%20domain_read%20identity_provider_read%20permission_read%20group_read&client_id=YOUR_KEY&redirect_uri=https://developers.docusign.com/platform/auth/consent
```

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:

| Script | Needs | Notes |
| - | - | - |
| **Accounts** | Account admin | Each eSignature account: plan, plan dates, seats allowed and in use, suspended or sending blocked. |
| **Users** | Account admin | Every user on each account, including closed and disabled ones: status, admin flag, permission profile, last login, groups, and whether they can send, manage the account or call the API. |
| **Permission Profiles** | Account admin | What each profile allows (account management, sending, API access, sending on behalf of others, bulk send, templates) and how many users hold it. |
| **Groups** | Account admin | Administrators, Everyone and custom groups, with the permission profile they grant and member count. |
| **Group Members** | Account admin | Who is in each Administrators and custom group. |
| **Connect Webhooks** | Account admin, a plan with Connect | Where Connect pushes envelope events: destination host, whether documents are included, which events, how the receiver is authenticated. |
| **Organization Users** | Organization admin | Every user of every account in the organization, with user and membership status and SCIM management. |
| **User Profiles (last login)** | Organization admin | Last login, organization admin, single sign-on status, two-step verification, and every account membership. Refreshes up to 400 people a run, stalest first. |
| **Claimed Domains** | Organization admin | Email domains your organization claimed, their verification status and linked identity provider. |
| **Identity Providers (SSO)** | Organization admin | Single sign-on setup: name, issuer, auto-provisioning, certificate expiry. |
| **Monitor Audit Events** | Docusign Monitor add-on | Logins, admin and permission changes, user changes and API activity, kept permanently. |

2. 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.

| Table | Source | Key Columns |
| - | - | - |
| `docusign_accounts` | `GET /oauth/userinfo`, `GET /restapi/v2.1/accounts/{accountId}` | account\_id, account\_name, is\_default, base\_uri\_host, plan\_name, plan\_classification, plan\_start\_date, plan\_end\_date, billing\_period\_end\_date, seats\_allowed, seats\_in\_use, envelope\_sending\_blocked, suspension\_status, suspension\_date, connect\_permission, created\_date |
| `docusign_users` | `GET /restapi/v2.1/accounts/{accountId}/users` | account\_id, user\_id, user\_name, email, first\_name, last\_name, user\_status, user\_type, is\_admin, is\_alternate\_admin, permission\_profile\_id, permission\_profile\_name, last\_login, created\_date, added\_to\_account\_date, license\_type, is\_managed\_by\_scim, job\_title, can\_send\_envelope, can\_manage\_account, can\_manage\_templates, can\_send\_api\_requests, api\_account\_wide\_access, allow\_send\_on\_behalf\_of, bulk\_send, group\_names |
| `docusign_permission_profiles` | `GET /restapi/v2.1/accounts/{accountId}/permission_profiles` | account\_id, profile\_id, profile\_name, user\_count, modified\_at, modified\_by, allow\_account\_management, allow\_envelope\_sending, allow\_api\_access, allow\_api\_access\_to\_account, allow\_api\_sending\_on\_behalf\_of\_others, allow\_bulk\_sending, allowed\_template\_access, allowed\_address\_book\_access, power\_form\_role, settings\_json |
| `docusign_groups` | `GET /restapi/v2.1/accounts/{accountId}/groups` | account\_id, group\_id, group\_name, group\_type, permission\_profile\_id, users\_count, last\_modified\_on, is\_managed\_by\_scim |
| `docusign_group_members` | `GET /restapi/v2.1/accounts/{accountId}/groups/{groupId}/users` | account\_id, group\_id, group\_name, group\_type, user\_id, user\_name, email, user\_status |
| `docusign_connect_configs` | `GET /restapi/v2.1/accounts/{accountId}/connect` | account\_id, connect\_id, name, configuration\_type, endpoint\_host, delivery\_mode, all\_users, user\_count, group\_count, include\_documents, include\_document\_fields, include\_certificate\_of\_completion, include\_hmac, include\_oauth, sign\_with\_x509, require\_mutual\_tls, allow\_envelope\_publish, pause\_publish, disabled\_by, enable\_log, requires\_acknowledgement, event\_names |
| `docusign_org_users` | `GET /management/v2/organizations/{organizationId}/users` | organization\_id, organization\_name, account\_id, user\_id, user\_name, email, first\_name, last\_name, user\_status, membership\_status, created\_on, closed\_on, membership\_created\_on, membership\_closed\_on, is\_managed\_by\_scim, is\_membership\_managed\_by\_scim, license\_type, plan\_name |
| `docusign_org_user_profiles` | `GET /management/v2.1/organizations/{organizationId}/users/{userId}/dsprofile` | organization\_id, user\_id, user\_name, email, user\_status, is\_organization\_admin, is\_account\_admin, last\_login, created\_on, federated\_status, require\_two\_step\_verification, device\_verification\_enabled, is\_managed\_by\_scim, default\_account\_id, membership\_count, memberships\_json |
| `docusign_reserved_domains` | `GET /management/v2/organizations/{organizationId}/reserved_domains` | organization\_id, domain\_id, host\_name, domain\_status, identity\_provider\_id, settings\_json |
| `docusign_identity_providers` | `GET /management/v2/organizations/{organizationId}/identity_providers` | organization\_id, idp\_id, friendly\_name, idp\_type, auto\_provision\_users, issuer, certificate\_count, earliest\_certificate\_expiry, any\_certificate\_invalid, settings\_json |
| `docusign_monitor_events` | `GET https://lens.docusign.net/api/v2.0/datasets/monitor/stream` | event\_id, event\_time, organization\_id, account\_id, user\_id, integrator\_key, object\_name, action\_name, property\_name, field\_name, result, source, ip\_address, country, state, city, browser, os, device, affected\_user\_id, referenced\_user\_id, is\_user\_member\_of\_domain, proxy\_status, data\_ids\_json |

***

## 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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.