PandaDoc package v1.0.0

A PandaDoc 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 <access_token>'. PandaDoc documents OAuth 2.0 as the recommended authentication method for all new integrations and the 'API-Key' header as a legacy method maintained for backwards compatibility with existing integrations.

This pack registers only the OAuth credential: the official documentation retrieved for this review does not establish the API key's issuance, expiry or revocation contract, so the API-key option was removed rather than registered on an unresolved custody model — a deployment that wants the legacy key must complete that review itself. 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.

Token lifecycle, per PandaDoc's Create/Refresh Access Token reference: the authorization code is one-time-use; the access token's expires_in is 31,535,999 seconds (one year) as currently documented — read expires_in rather than hard-coding a duration — and an expired token returns 401; the stored refresh_token is then exchanged for a new access token at POST /oauth2/access_token with grant_type=refresh_token.

The client secret stays with the external process, which must own minting and refresh and write 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.

The retrieved reference documents no token-revocation endpoint and no refresh-token rotation or lifetime semantics, so the completed custody review documents revocation and refresh-token expiry as unresolved vendor-side properties: the cut-off path is an account-side administrative action the deployment must confirm with PandaDoc, and this pack makes no stronger claim.

Least privilege: PandaDoc documents two scopes, 'read' (view templates and document details) and 'write' (create, send, delete and download documents), and documents 'read+write' as deprecated in favor of 'read write'. This pack needs 'read write' when the create and send capabilities are enabled — note that 'write' also authorizes document deletion, which this pack excludes; that residual breadth is a documented trade-off of the vendor's scope model, not an oversight.

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.

Every capability in this pack targets PandaDoc's real shared API host api.pandadoc.com, so no host substitution is required; the only placeholder is DOCUMENT_ID in the send path, an UPPERCASE path segment the deployment binds to a concrete document before enabling. This pack registers only endpoints verified against the official PandaDoc API reference at developers.pandadoc.com: listing documents, listing templates, listing contacts, creating a document, and sending a document.

All reads are collection reads only — single-record paths (document details, template details, contact details) are not registered. Consequential effects: PandaDoc documents that sending a document emails the recipients a link to view and sign it, so document send is declared send at the minimum R3 tier — send is one of the designated actions requiring human approval, a sent document cannot be recalled after delivery.

On supported execution paths mediated by AAES Govern, irreversible actions require approval by an authorized person; this does not prevent calls through bypass or observation-only paths. Document creation is declared create at the minimum R2 tier: it brings a new document into existence but does not itself notify recipients — PandaDoc documents that a created document sits in document.uploaded and then document.draft status until a separate send call.

Documented exclusions, framed as what this pack does not register: document update and document status change (PATCH, including voiding a sent document), document delete and bulk delete, document download and export, document recipient/field/section/attachment management, manual reminders (a further send surface), document ownership update and transfer-all-ownership (a transfer effect), template creation/update/duplication/deletion, content library items, forms, contact create/update/delete, catalog items and quotes, notary requests, webhook subscriptions, workspace/user/member administration, and API-key creation.

Authentication: PandaDoc documents two methods, an Authorization: 'API-Key <key>' header (documented as legacy, maintained for backwards compatibility) and OAuth 2.0 bearer tokens (documented as recommended for all new integrations); see the credential note for what the stored value must be. This pack registers the OAuth method only: the reviewed documentation does not establish the legacy API key's issuance, expiry or revocation contract, so that credential option was removed (see the credential note).

Credential review completed on 2026-09-21 for an OAuth access token held in the customer's vault and refreshed by an external process. The requirements and limits are below.

Issuance authority and delegation: tokens are minted by PandaDoc's OAuth server through the authorization-code flow — the authorization code is one-time-use — and PandaDoc documents OAuth 2.0 as the recommended authentication method for all new integrations, with the 'API-Key' header a legacy method whose issuance, expiry and revocation contract the reviewed documentation does not establish.

Scope: PandaDoc documents two scopes, 'read' (view templates and document details) and 'write' (create, send, delete and download documents), with 'read+write' deprecated in favor of 'read write'; this pack needs 'read write' when the create and send capabilities are enabled, and 'write' also authorizes document deletion, which this pack excludes — a limitation of the vendor's scope model.

Audience: no audience mechanism is documented — the bearer value authorizes against api.pandadoc.com, and audience binding beyond that is not established. TTL: the access token's expires_in is 31,535,999 seconds (one year) as currently documented — read expires_in rather than hard-coding a duration — and an expired token returns 401.

Refresh ownership: the client secret stays with the external process, which owns minting and refresh (the stored refresh_token is exchanged at POST /oauth2/access_token with grant_type=refresh_token) and 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.

Revocation: the retrieved reference documents no token-revocation endpoint and no refresh-token rotation or lifetime semantics — the completed review documents this gap: the cut-off path is an account-side administrative action the deployment must confirm with PandaDoc, and this pack makes no stronger claim.

Executor access and replay/exposure: the executor reads only the vault reference; the token is a bearer credential replayable for up to its documented one-year TTL with no vendor revocation endpoint — so vault-only storage and the executor hygiene bar are the controlling mitigations.

Alternate access paths: the PandaDoc web app and any legacy API-Key integrations retain access outside this pack, and ending this integration's access closes only this path. The credential review is complete. Assign accountable owners before deployment.