workday 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-workday-oauth

Custody

customer_vault

Injection

header (Authorization)

An OAuth2 access token for the tenant's REST API, minted from an API Client for Integrations registered in the customer's own tenant and held in the customer's own secret manager under customer_vault. The stored material must be the complete Authorization header value (scheme included); storing client credentials or a refresh token under this reference does not make the HTTP injector perform OAuth. Refresh ownership: an external deployment process, outside AAES, obtains and renews the token via the refresh-token grant against the tenant token endpoint (https://{host}/ccx/oauth2/{tenant}/token) using the client ID, client secret and an Integration System User's refresh token, and writes the fresh header value into customer_vault before the old one expires; Workday access tokens are short-lived (confirm the actual TTL in the deployment — it is an open review item below), so the renewal cadence must be strictly tighter than the TTL. Expiry/revocation: treat the token as expired on any 401 and on schedule, whichever comes first; revocation is performed in the tenant against the API client and the ISU's refresh token, and the external process must stop writing renewed values once revocation is intended. Whether the refresh token is non-expiring is a choice made at registration in the tenant — choose expiring and rotate. Executor hygiene: the executor resolves this reference into memory per call; it must not log the header value, must not persist it to crash dumps or diagnostics, and must scope vault read access to this reference only. Completed custody review items: the external token-renewal process feeding customer_vault (documented above), refresh ownership (the deployment's external process, not AAES), expiry/revocation handling (above) and executor-memory/log/crash hygiene (above). Open review questions before any promotion: issuance authority and delegation chain inside the customer's tenant, the minimum functional scopes and matching ISU domain-security policies per capability (Staffing for workers; Organizations and Roles for supervisory organizations — scope caps the token, and the ISU's domain security must also allow each call), token audience, actual TTL as observed in the deployment, and executor access and bypass paths.

• workday-tenant (api, pii): https://workday-datacenter.invalid/ccx/api

Every endpoint host ('workday-datacenter.invalid') and the TENANT path segment are placeholders: replace them with the deployment's data-center host (for example wd2-impl-services1.workday.com) and tenant name before enabling, in the endpoints and in the egress allowlist — both are shown on the tenant's View API Clients report, which also shows the OAuth2 token endpoint (https://{host}/ccx/oauth2/{tenant}/token). The .invalid host is a reserved non-production authority (RFC 2606) that fails closed until substituted; substitution is a reviewed pre-enablement step, not something to delegate to provider rejection of a literal placeholder. Review outcome, stated plainly: the external promotion review of 2026-09-21 (GPT-6 Astra) held this pack at draft pending verification of the recruiting and absence-management endpoints against provider-hosted documentation, and the pack remains in state draft. Verification round 2026-09-21 — what was attempted and what was retrieved: (1) Workday's authoritative REST Services Directory (community.workday.com, file-hosting/restapi/index.html) was fetched again and is still gated behind a customer login: only its JavaScript shell loads, so no per-resource operation list was read from it — an inaccessible directory shell is not evidence of an endpoint, nor of an API's absence. (2) Workday's public developer-education material (doc.workday.com) was re-read; it documents the common/v1 workers and supervisoryOrganizations surface with live response examples and remains the basis for the two retained registrations. (3) developer.workday.com was retrieved; it publishes no open per-operation REST reference without an account. (4) No Workday-hosted, dated document supporting the exact method+path of GET /ccx/api/recruiting/v4/{tenant}/jobPostings, GET /ccx/api/absenceManagement/v1/{tenant}/balances or POST /ccx/api/absenceManagement/v1/{tenant}/workers/{id}/requestTimeOff could be retrieved. Third-party corroboration exists — integration vendors document these or sibling paths, practitioners report calling them, and search-index snippets of the gated directory mention an absence-balances GET under absenceManagement v5 — but corroboration is not named provider documentation. Consequently, per the review's instruction, workday.job-postings.read, workday.absence-balances.read and workday.time-off-requests.create were REMOVED from this pack on 2026-09-21: an unverifiable endpoint must not sit in an installable pack, draft or not. Documented exclusions — framed as what this pack does not register, without universal claims about Workday's API surface: payroll execution or mutation, offer-letter generation, job-requisition creation, worker hire, compensation changes, business-process approvals, and the three removed capabilities above, which stay excluded until each exact method, path and version is verified against provider-hosted documentation (the tenant's own REST API Explorer counts) and re-registered with the dated source recorded. Whether worker hire exists only on the legacy SOAP Staffing web service, and whether payroll REST resources are read-only, are claims this pack no longer makes; the SOAP services (/ccx/service/{tenant}/...) are simply out of scope — WS-Security ISU credentials and per-tenant WSDL versions are a different credential and review surface. Data-class consideration recorded from the review: absence balances and time-off data can reveal health-adjacent information, so if absence capabilities are ever re-registered the deployment must revisit the data classification and handling requirements, not merely the risk tier. Custody model: an externally refreshed OAuth access token held in the customer's vault — see credential.note for the completed custody items; the items that remain open review questions before any promotion are issuance authority and delegation inside the customer's tenant, functional scopes and domain-security mapping per capability, token audience, actual TTL as observed in the deployment, executor access and bypass paths, and conformance against the capability-library plan (docs/gtm/CAPABILITY-LIBRARY-PLAN.md §4) gates. Confirm each resource and version (common v1) in the tenant's own REST API Explorer before enabling, because the REST surface is tenant-specific and version availability varies. AAES has not been certified by Workday; the endpoints here are a reviewable default, not a vendor guarantee.

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

• https://doc.workday.com/workday-education/en-us/course-manuals/workday-extend-for-developers/relationships-between-business-objects.html (retrieved 2026-09-21)
• https://community.workday.com/sites/default/files/file-hosting/restapi/index.html (retrieved 2026-09-21) — login-gated: only the JavaScript shell loads, no operation list read
• https://developer.workday.com/ (retrieved 2026-09-21) — no open per-operation REST reference without an account

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.