Reference · built on requestConnectorHR, scheduling & workforce

Dayforce

Employees, schedules, punches, time away, and pay data from Dayforce RESTful Web Services, one client namespace per organization.

About

Dayforce is a single-application HCM platform for HR, payroll, time, and scheduling. Its RESTful Web Services Developer Guide documents endpoints under https://www.dayforcehcm.com/api/{clientName}/V1/, where clientName is your organization's namespace. Resources cover employees, org units, departments, jobs, positions, schedules, punches, availability, time away from work, pay summaries, pay adjustments, labor metrics, and reports.

Through Fibric, an operator reads schedules and punches for a date range, compares them with pay summaries, and proposes a punch, a schedule change, or an availability entry. You confirm it. The request goes out once, and a receipt shows what changed.

This is a reference listing. It documents what Fibric would read from Dayforce 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

  • Employee details through GET /Employees and GET /Employees/{XRefCode}, with subordinate resources per employee
  • Schedules by date range through GET /EmployeeSchedules, filtered by employee, department, job, position, or org unit, with unfilled shifts on request
  • Availability, schedules, and time away from work per employee under /Employees/{xRefCode}/Availability, /Schedules, and /TimeAwayFromWork
  • Clock entries through GET /EmployeePunches and raw clock data through GET /EmployeeRawPunches, filtered by transaction time
  • Pay summaries and pay adjustments through GET /EmployeePaySummaries and GET /EmployeePayAdjustments
  • Report metadata and report data through /ReportMetadata and /Reports, paged with a cursor
  • Org units, departments, jobs, and positions, each addressed by XRefCode

Proposed actions

  • Target capability: propose a time entry through POST /EmployeePunches, validated first with isValidateOnly=true
  • Target capability: propose a raw clock entry through POST /EmployeeRawPunches
  • Target capability: propose adding or changing a schedule through POST and PATCH /EmployeeSchedules
  • Target capability: propose an employee availability entry through POST Availability
  • Target capability: propose a pay adjustment through POST /EmployeePayAdjustments

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Tell staff about schedule changes

    Employee schedules are read by date range. When a shift moves, the operator proposes the notice to send and the channel, and records who was told.

    With Schedule Notice

  • Fix a missing punch the same day

    EmployeePunches show a shift with a start and no end. The operator proposes the punch through POST /EmployeePunches, validated first, for a manager to approve.

    With Missed Punch

  • Stop overtime before it starts

    Schedules and punches for the week are summed per employee. Near the threshold you set, the operator proposes a schedule change for approval.

    With Overtime Guard

  • Keep labor inside budget

    Pay summaries and scheduled hours feed a daily read of labor cost by org unit. The operator proposes where to trim and shows the numbers behind it.

    With Labor Budget

Requirements

  • A Dayforce user account whose default role includes HCM Anywhere > Web Services with at least the Read Data subfeature
  • The Patch/Post/Delete Employee Time Entry role feature for punch writes
  • Access authorizations and field-level access configured for the web services role
  • Your client namespace, and a daily call to /V1/ClientMetadata to obtain the version-specific ServiceUri
Authentication
HTTP basic authentication with a Dayforce user whose default role has the Web Services feature, or an access token from the Dayforce identity service obtained with those same credentials.

Limits

  • Rate limits apply per client: Get Employee HR Details by XRefCode allows 10 XRefCodes per second or 100 per minute
  • Every request is redirected to the version-specific host unless you cache the ServiceUri from ClientMetadata
  • Access tokens cannot be revoked once issued
  • Large responses such as Reports and Employee Punches are paged; follow Paging.Next until it is empty

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.

Request Dayforce ↗

Questions and answers

Which URL does Dayforce use?
All clients call https://www.dayforcehcm.com/api/{clientName}/V1/ and Dayforce redirects each request to the correct service version. To skip the redirect, call /V1/ClientMetadata at least once a day and use the ServiceUri it returns, which embeds the version number.
How does authentication work?
Requests use HTTP basic authentication with a user whose default role has the Web Services feature enabled under System Admin > Roles. Dayforce also issues access tokens from its identity service in exchange for those credentials. Tokens expire but cannot be revoked, so Dayforce asks that they be handled with care.
Are there rate limits?
Yes. The limiter applies per client, not per application, so you allocate requests across your integrations. Get Employee HR Details by XRefCode is limited to 10 XRefCodes per second or 100 per minute. Heavier operations such as Get Reports have lower thresholds, and requests over the limit are denied.
Ask about Dayforce

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.