Tableau package v1.0.0

A Tableau credentials token (session token) for one site, held in the client's own secret manager. The stored material must be the complete X-Tableau-Auth header value — the token string returned by Sign In, verbatim. Token issuance is an external process this pack does not register: the deployment's custody job calls Sign In (POST /api/{api-version}/auth/signin) with a personal access token name and secret and the site's contentUrl, parses the credentials token, site LUID and user LUID out of the response, and writes the token under this reference.

Tableau strongly recommends PAT sign-in over username and password; on Tableau Cloud with MFA, a PAT (or a connected-app/UAT JWT flow, which this pack does not register) is required. The PAT itself is long-lived (Tableau Server: one year by default; Tableau Cloud: per the site setting; unused PATs expire after 15 consecutive days) and should live in a separate vault entry the sign-in job reads — the value under THIS reference is the session token.

Expiry and revocation: the credentials token expires after 240 minutes IDLE by default, tunable via wgserver.session.idle_limit — an idle timeout, not a bounded maximum lifetime: active use keeps extending the session, and the reviewed documentation states no hard cap — and the token is site-scoped: it returns 403 against any other site. The custody job must re-sign-in and update the stored value before expiry; an expired value fails closed with a 401.

Sign Out invalidates the token immediately. Note carefully: the reviewed documentation does NOT state whether revoking a PAT invalidates credentials tokens already issued from it — the deployment must assume an issued token may remain usable until it expires or is signed out, so the session idle timeout is the effective revocation window and should be set accordingly.

Least privilege: issue the PAT to a dedicated service-account user with the minimum site role that covers these capabilities, and use one PAT per integration so revocation is granular (a user may hold multiple PATs).

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.

The endpoint host 'tableau-instance.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's Tableau Server base URL — or, for Tableau Cloud, the pod host such as <pod>.online.tableau.com — before enabling, in every endpoint, in the resource locators and in every egress allowlist entry; the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. SITE_ID, WORKBOOK_ID and DATASOURCE_ID in the paths are placeholders the deployment binds to concrete values before enabling, and SITE_ID is the site LUID returned by the Sign In response for the site the deployment governs.

The paths PIN REST API version 3.29: the fetched reference pages present 3.29 as the current version and the operation contracts registered here were reviewed against those pages — a deployment that binds a different version must re-review the operations, because capabilities vary by version. Session-token model, these endpoints do not accept the stored vault secret directly. An external deployment process calls Sign In (POST /api/{version}/auth/signin) with a personal access token name and secret plus the site's contentUrl, receives a short-lived credentials token and the site LUID, and stores the token as the complete X-Tableau-Auth value under the vault reference — see the credential note for the full lifecycle.

This pack registers no auth/signin or auth/signout capability: session establishment is the credential process, not a governed business operation.

Documented exclusions — this pack does not register: Add User to Site and site-role changes (access granting — share-class operations requiring their own review); the permissions endpoints (Add/Delete Workbook or Data Source Permissions — direct ACL grants on content); Create Subscription (emails workbook content to recipients on a schedule — send-class, and a share of rendered data outside the platform); Publish Data Source and publish-append/replace modes (content publication the integration does not require); server-administration endpoints (Create Site, server settings, server-info configuration); flow and extract-refresh task management; Sign In with the user element (server-administrator impersonation of another user); connected-app and unified-access-token JWT sign-in flows; and the encrypted keychain endpoints (retrieveKeychain/uploadKeychain migrate embedded credentials between servers — credential-material movement, excluded outright).

These operations are excluded.

Approval classification: publish and extract refresh are registered with the deploy action at the minimum R3 tier — they change the content and data every viewer of the site consumes, which is deploy-equivalent; deploy is one of the designated actions requiring human approval. Update Workbook is registered update, share and transfer at the minimum R3 tier because its unrestricted body can change the workbook's owner and project, and moving a workbook into a project changes its effective permissions through project permission inheritance — an access change, not a cosmetic edit.