Workday is a cloud HCM suite that runs as a tenant on a Workday-hosted URL. Its REST Services Directory publishes an OpenAPI 2.0 schema per service: Absence Management v5, Staffing v7, Time Tracking v6, Person v4, and Common v1 among them, each rooted at https://<tenantHostname>/<service>/<version>. Every endpoint is secured by one or more Workday security domains and a functional scope. Older SOAP services such as Human_Resources and Time_Tracking remain in the Workday Web Services directory.
An operator on Fibric reads workers, absence balances, time clock events, and time blocks, and proposes time off requests or check-in corrections for your approval. Each proposal leaves a receipt: what changed, why, and how to undo it.
This is a reference listing. It documents what Fibric would read from Workday and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.
Inputs
Workers and current staffing information through GET /workers in the Staffing v7 and Absence Management v5 services
Absence plan and leave of absence balances per worker through GET /balances in Absence Management v5
Time off details, leaves of absence, and eligible absence types for a worker, addressed by Workday ID, Employee_ID, or me
Time clock events, check in and check out, for a worker over a date range through GET /timeClockEvents in Time Tracking v6
Worker time blocks and a summary of reported hours per period through /workerTimeBlocks and /workers/{ID}/timeTotals
Supervisory organizations with their members and org charts, plus job profiles, job families, and jobs
Change Job and Change Organization Assignment events through the Staffing v7 jobChanges and organizationAssignmentChanges resources
Proposed actions
Target capability: propose a time off request for a worker through POST /workers/{ID}/requestTimeOff, which starts the Request Time Off business process
Target capability: propose a time off correction through POST /workers/{ID}/correctTimeOffEntry
Target capability: propose check-in and check-out events for workers through POST /timeClockEvents
Target capability: propose a worker time block through POST /workers/{ID}/workerTimeBlock
Target capability: propose a Change Job request through POST /workers/{ID}/jobChanges, its PATCHed details, and POST /jobChanges/{ID}/submit
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Catch a missed punch before the period closes
Read time clock events and time totals for the period, flag workers with an open check-in or no reported hours, and propose the correction for a manager to approve.
A Workday tenant and its hostname; each REST service is rooted at https://<tenantHostname>/<service>/<version>
An OAuth 2.0 client the tenant authorizes for the functional scopes in use, for example Time Off and Leave, Staffing, and Time Tracking
Security domain access for each endpoint, for example Process: Time Clock Event REST API's or FLW Service
A Workday Community login to read Workday's own authentication and setup guides, which are not public
Authentication
OAuth 2.0 against the tenant's authorization hostname, as declared in each service's OpenAPI schema; the tenant grants the security domains each endpoint names.
Limits
Endpoints are gated by Workday security domains and business process types; an endpoint the tenant has not opened cannot be read
Requesting time off is a three-step sequence: eligibleAbsenceTypes, then validTimeOffDates, then requestTimeOff as a multipart request
GET /workerTimeBlocks omits incomplete time blocks, time offs, and overtime request blocks; the Staffing workers resource covers non-terminated workers only
Workday's REST Services Directory documents no request rate limits; pacing is agreed per deployment
Access and pricing
Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.
Absence Management v5, Staffing v7, and Time Tracking v6 from Workday's REST Services Directory, each with its own OpenAPI 2.0 schema. Person v4 and Common v1 cover contact and organization data. Older SOAP services such as Human_Resources remain in the Workday Web Services directory at v47.0.
How is a REST call authorized in Workday?
With OAuth 2.0. Each service schema declares an OAuth2 security definition against the tenant's authorization hostname, and each endpoint names the security domain and functional scope it is secured by, for example FLW Service and Time Off and Leave. Your tenant administrator grants those domains.
Can the connector identify a worker without a Workday ID?
Yes. Worker endpoints accept a 32-character Workday ID, a reference ID in the form Employee_ID=value or Contingent_Worker_ID=value, or the named entry me for the calling user.
Ask about Workday
Ask about the capabilities and requirements in this listing.
This connector listing is developed, published, and supported by Fibric. It describes integration with Workday through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy