pardot 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-pardot-salesforce-oauth

Custody

customer_vault

Injection

header (Authorization)

A Salesforce OAuth 2.0 access token, held in the client's own secret manager, minted by an external process from a connected app whose selected OAuth scopes include pardot_api, for an SSO-enabled integration user (one who can log in with Salesforce or use the Account Engagement Lightning App). The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the token. Session and renewal policy: the retrieved Account Engagement authentication page documents the OAuth prerequisites (a connected app with the pardot_api scope, an SSO-enabled user, and the Pardot-Business-Unit-Id header) and that the Web Server Flow is the most commonly used of the supported OAuth 2.0 flows, with renewal following the flow the connected app allows (a refresh_token flow or JWT bearer flow); refresh ownership sits entirely with the external process — the executor injects the stored value verbatim and performs no token lifecycle itself. The specific session/connected-app expiry policy page (Salesforce Help) could not be retrieved for this review — it renders JavaScript-only — so this pack deliberately makes no numeric claim about access-token lifetime: the deployment must verify the connected app's session/timeout policy against Salesforce's own session-settings documentation before enabling, and that check is part of the unfinished custody review. Every Account Engagement API v5 request must also carry the Pardot-Business-Unit-Id header with the target business unit's id (18 characters, beginning 0Uv); the id is configuration rather than credential material, but the deployment must wire it alongside the credential. Least privilege, per the documented ability requirements: Prospect > Prospects > View for prospect reads, Marketing > Segmentation > Lists > View for list reads, Marketing > Other > Campaigns > View for campaign reads, Prospect > Visitors > View for visitor reads, and Marketing > Segmentation > Create with Prospect > Prospects > Create only if the list-membership capability is enabled. Revocation: revoke the token or the connected app's authorization in Salesforce; an expired or revoked value fails closed. 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.

• pardot-prospects (api, pii): https://pi.pardot.com/api/v5/objects/prospects
• pardot-lists (api, internal): https://pi.pardot.com/api/v5/objects/lists
• pardot-campaigns (api, internal): https://pi.pardot.com/api/v5/objects/campaigns
• pardot-visitors (api, pii): https://pi.pardot.com/api/v5/objects/visitors

The endpoint host is a real shared Account Engagement host: production and training environments are served from pi.pardot.com, and demo, developer-org and sandbox environments from pi.demo.pardot.com. This pack registers the production host; a deployment against a sandbox substitutes pi.demo.pardot.com in the endpoints, the resource locators and the egress allowlist together — the allowlist matches exactly. There is no per-customer host placeholder here, but every request must carry the business unit in the Pardot-Business-Unit-Id header (an 18-character id beginning 0Uv, found in Salesforce Setup > Business Unit Setup): that id is configuration, not a secret, and the deployment must wire it for the executor, because a request without it fails even with a valid token. The pack pins API version 5 deliberately: versions 3 and 4 are legacy. Version 5 reads can be served from a cache that runs up to roughly 60 seconds behind the primary data, so a read is not a real-time guarantee. Reads are registered against the query (collection) endpoints only: single-record reads (GET /api/v5/objects/prospects/<id>, /lists/<id>, /campaigns/<id>, /visitors/<id>) are not registered by this pack. Effect-level tiering: marketing automation is send-first. Creating a list membership adds a prospect to a static email list, and Account Engagement documents lists as groups of prospects used to send list emails or to feed engagement programs — membership CAN initiate communication through an active program or list-email send, though membership alone does not guarantee an email is sent; once a send occurs it cannot be recalled — so the capability declares create and send, and send keeps the tier at the R3 floor; send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). Documented exclusions — this pack does not register: prospect create, update, delete, upsert (upsertLatestByEmail) or undelete; list create, update or delete; list-membership update (including the optedOut flag, which the documentation states can be set to opt a prospect out of a list's emails but cannot be set back — a one-way change a reviewer should enable separately) and list-membership delete; visitor assignToProspect and identifyCompany; campaign connectSalesforceCampaign; engagement-studio program management (not part of the v5 object surface reviewed here); the legacy v3/v4 endpoints, including their one-off email send operations; and the Export API. The review state is draft, not library, for a concrete reason: this pack's custody model — a Salesforce 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://developer.salesforce.com/docs/marketing/pardot/guide/overview.html (retrieved 2026-09-21)
• https://developer.salesforce.com/docs/marketing/pardot/guide/version5overview.html (retrieved 2026-09-21)
• https://developer.salesforce.com/docs/marketing/pardot/guide/authentication.html (retrieved 2026-09-21)
• https://developer.salesforce.com/docs/marketing/pardot/guide/prospect-v5.html (retrieved 2026-09-21)
• https://developer.salesforce.com/docs/marketing/pardot/guide/list-v5.html (retrieved 2026-09-21)
• https://developer.salesforce.com/docs/marketing/pardot/guide/campaign-v5.html (retrieved 2026-09-21)
• https://developer.salesforce.com/docs/marketing/pardot/guide/visitor-v5.html (retrieved 2026-09-21)
• https://developer.salesforce.com/docs/marketing/pardot/guide/list-membership-v5.html (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.