docusign v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-docusign-oauth-token

Custody

customer_vault

Injection

header (Authorization)

A Docusign OAuth 2.0 access token, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the access token — 'Bearer <token>'. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only. Two grant types produce the stored token, and they differ in whose identity the token carries. Authorization Code Grant (Confidential, or Public with PKCE): the integration acts on behalf of the individual user who granted consent and is present to authenticate; tokens expire after eight hours by default and come with a refresh token. JWT Grant: a service integration that impersonates (acts as) a specific user on a long-term basis without that user being present — it requires the 'signature' scope plus the 'impersonation' scope, and Docusign issues tokens only after documented consent to act on behalf of the impersonated user (individual consent, or admin consent via Docusign Admin for an organization); JWT Grant tokens expire after one hour and the flow grants no refresh token, so each renewal builds a new JWT and exchanges it. Minting and refresh MUST be owned by an external deployment process that writes the fresh header value into the vault — the executor injects the stored value verbatim and performs no token lifecycle itself, and a stale value fails closed. Token revocation is likewise an external operation against the Docusign authentication service. Least privilege: request only the scopes these capabilities need — 'signature' for Authorization Code Grant, or 'signature impersonation' for JWT Grant with its consent requirement. The 'extended' scope is not a generic requirement for unattended refresh: Docusign documents it as a special scope for Authorization Code Grant integrations, and the documented rolling behavior is that refreshing with the extended scope renews the refresh token's 30-day lifetime on each use — sustained use keeps the grant alive without re-consent, while 30 days of inactivity expires it. Request it only where that documented refresh-lifetime behavior applies. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• docusign-account-envelopes (api, pii): https://docusign-account.invalid/restapi/v2.1/accounts/ACCOUNT_ID/envelopes
• docusign-account-templates (api, internal): https://docusign-account.invalid/restapi/v2.1/accounts/ACCOUNT_ID/templates
• docusign-account-users (api, pii): https://docusign-account.invalid/restapi/v2.1/accounts/ACCOUNT_ID/users

The endpoint host 'docusign-account.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the account's own eSignature base URI host before enabling, in the endpoints, the resource locators and the egress allowlist — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. Docusign assigns each account a per-region account server; the real substitution shape is '{server}.docusign.net' (for example 'na4.docusign.net'; the demo environment is 'demo.docusign.net'), and the deployment obtains the account's base URI from the OAuth userinfo response. ACCOUNT_ID in the endpoint paths is a placeholder for the Docusign account id: replace it before enabling. This pack registers only endpoints the official eSignature REST API v2.1 reference (and Docusign's published OpenAPI specification) documents: searching envelopes by status and date (listStatusChanges), listing templates, listing users, and creating an envelope. Reads are collection reads: single-record reads (GET .../envelopes/{envelopeId}, GET .../templates/{templateId}, GET .../users/{userId}), document and recipient retrieval, and audit events are not registered by this pack. Documented exclusions: this pack does not register envelope update (PUT .../envelopes/{envelopeId}, which can send a draft, void an in-flight envelope or purge documents), recipient modification, bulk-send operations, Connect webhook configuration, template creation, and user creation, update or closure — deliberate exclusions, not approximated capabilities. Envelope content is contractual material about identifiable signers, so envelope data is registered at the pii class. The review state is draft, not library, for a concrete reason: this pack's custody model — an OAuth access token held in the customer's vault and refreshed by an external process — has not yet been reviewed against the properties the capability-library plan (docs/gtm/CAPABILITY-LIBRARY-PLAN.md §4) gates any authentication mode on: issuance authority and delegation, scope, audience, TTL, refresh ownership, revocation, executor access and bypass paths. That review is unfinished.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://developers.docusign.com/docs/esign-rest-api/reference/envelopes/envelopes/ (retrieved 2026-09-21)
• https://raw.githubusercontent.com/docusign/OpenAPI-Specifications/master/esignature.rest.swagger-v2.1.json (retrieved 2026-09-21)
• https://developers.docusign.com/platform/auth/authcode/ (retrieved 2026-09-21)
• https://developers.docusign.com/platform/auth/jwt/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.