OVERALL CONTROL / 0.6-customer-control
Grades and scoring
Data access
25% of the overall score before applicability adjustment.
Scored answers and evidence
Read interface 7.5/10
Structured API for the declared product scope
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Unfiltered employee enumeration returns XRefCodes; fetch each permitted employee detail using ContextDate and selected Expand subresources. The current-as-of response is not full employee history.
Dayforce employee identifier enumeration ↗
Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective records · Checked 2026-10-16
Bulk delivery 8.8/10
Batched or iterable API requests
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Enumerate all employee XRefCodes without update filters, then retrieve details for each ID with fixed ContextDate/Expand and permissions. This is iterable scoped retrieval, not a database dump.
Dayforce employee identifier enumeration ↗
Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective records · Checked 2026-10-16
Dayforce current employee HR details ↗
One XRefCode per request; ContextDate and Expand; current effective selection rather than complete history · Checked 2026-10-16
Query expressiveness 8.8/10
Documented structured API filters
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Employee ID discovery supports paired update start/end filters, including changes in effective records. ContextDate and Expand control detail selection.
Dayforce employee identifier enumeration ↗
Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective records · Checked 2026-10-16
Access cost barrier -
-
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Lowest-paid-plan entitlement and complete fixed API or partner access fees are unresolved.
Dayforce REST authentication ↗
Web Services login credentials and default-role requirement · Checked 2026-10-16
Third-party accessibility
20% of the overall score before applicability adjustment.
Scored answers and evidence
Third-party eligibility -
-
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Customer administrators configure Web Services users and roles. The reviewed technical guides do not establish whether a chosen third-party provider needs a separate commercial agreement.
Dayforce REST authentication ↗
Web Services login credentials and default-role requirement · Checked 2026-10-16
Dayforce Web Services role configuration ↗
Enable Web Services on user role; field authorization separate · Checked 2026-10-16
Downstream permission -
-
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
The operation guides do not establish applicable downstream processing, AI-use or redistribution rights.
Dayforce REST authentication ↗
Web Services login credentials and default-role requirement · Checked 2026-10-16
External action
15% of the overall score before applicability adjustment.
Scored answers and evidence
Write interface 7.5/10
Create and update in one business domain
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
POST /Employees creates an employee; PATCH /Employees/{XRefCode} updates HR fields and permitted subresources. isValidateOnly checks validation without saving; omitted and null fields differ.
Dayforce add employee REST service ↗
POST /Employees; validation; employees persist and cannot be removed by this service · Checked 2026-10-16
Dayforce update employee REST service ↗
PATCH /Employees/{XRefCode}; null versus omitted fields; isValidateOnly; ProcessResult validation · Checked 2026-10-16
Custom application path -
-
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Customer credential setup alone does not establish chosen third-party production eligibility.
Dayforce REST authentication ↗
Web Services login credentials and default-role requirement · Checked 2026-10-16
Dayforce Web Services role configuration ↗
Enable Web Services on user role; field authorization separate · Checked 2026-10-16
Continuity
15% of the overall score before applicability adjustment.
Scored answers and evidence
Refresh mechanism 7.5/10
Documented updated-since filters or webhooks
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Poll paired update windows, fetch every returned XRefCode’s details, then advance the window only after that group completes. Effective-date changes also matter.
Dayforce employee identifier enumeration ↗
Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective records · Checked 2026-10-16
Limit visibility 10.0/10
Published numeric quotas and recovery instructions
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
The client-level guide gives employee-detail capacity as 10 XRefCodes/second or 100/minute, depending on operation; heavier operations can be lower. Queue denials and complete each ID group before starting the next.
Dayforce REST limits and request ordering ↗
Client-level allocation; employee detail example 10 XRefCodes/second or 100/minute; queue and sequential window completion · Checked 2026-10-16
CDC and deletion capture 5.0/10
Updates identified; deletion capture not established
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Updated employee identities are documented. Employee persistence and termination/status changes do not establish a hard-deletion stream or erased payload recovery.
Dayforce employee identifier enumeration ↗
Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective records · Checked 2026-10-16
Dayforce add employee REST service ↗
POST /Employees; validation; employees persist and cannot be removed by this service · Checked 2026-10-16
Replay and gap recovery 2.5/10
Rebuild from a fresh snapshot; no historical replay established
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Repeat unfiltered XRefCode enumeration and every permitted detail request at a declared ContextDate to rebuild current-as-of scoped HR records. Full history and deleted payloads are excluded.
Dayforce employee identifier enumeration ↗
Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective records · Checked 2026-10-16
Dayforce current employee HR details ↗
One XRefCode per request; ContextDate and Expand; current effective selection rather than complete history · Checked 2026-10-16
Data exit
20% of the overall score before applicability adjustment.
Scored answers and evidence
Export custody 7.5/10
Customer-held structured files or API records
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Permitted structured API records can form a customer-held copy.
Dayforce employee identifier enumeration ↗
Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective records · Checked 2026-10-16
Post-cancellation access Disclosure
-
Disclosure only; does not reduce planned-exit credit.
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Live retrieval does not establish contractual access after cancellation.
Dayforce employee identifier enumeration ↗
Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective records · Checked 2026-10-16
Planned migration fidelity 7.5/10
Portable structured records on documented routes; whole-product completeness unverified
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
The declared current record collection is portable; full history, files, configuration and whole-product reconstruction are unverified.
Dayforce employee identifier enumeration ↗
Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective records · Checked 2026-10-16
Business logic and customization
5% of the overall score before applicability adjustment.
Scored answers and evidence
Logic authoring 2.5/10
External integration code; native business logic portability not established
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
The documented route supports external integration code; native workflow authoring and portability are unverified (API clients are separate artifacts).
Dayforce REST authentication ↗
Web Services login credentials and default-role requirement · Checked 2026-10-16
Rights to custom logic -
-
Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate.
Rights to reusable native workflow definitions and independent execution are unresolved.
Dayforce REST authentication ↗
Web Services login credentials and default-role requirement · Checked 2026-10-16
Scores are out of 10. * Incomplete evidence discounts verified capabilities (unknown answers stay unknown). Planned migration drives data exit. Scoring method ↗
CUSTOMER CHOICE
Third-party accessibility
Customer administrators configure Web Services users and roles. The reviewed technical guides do not establish whether a chosen third-party provider needs a separate commercial agreement.
Confirm who can connect, who owns the credentials and which uses are permitted. Customer consent and provider approval can be separate requirements; the selected plan and contract still matter.
READ / INTEGRATE
API and export routes
Unfiltered employee enumeration returns XRefCodes; fetch each permitted employee detail using ContextDate and selected Expand subresources. The current-as-of response is not full employee history. Enumerate all employee XRefCodes without update filters, then retrieve details for each ID with fixed ContextDate/Expand and permissions. This is iterable scoped retrieval, not a database dump. Employee ID discovery supports paired update start/end filters, including changes in effective records. ContextDate and Expand control detail selection.
| Access route | Authentication | Credential owner | Provider approval | Access requirement | Last checked |
|---|---|---|---|---|---|
| Dayforce customer Web Services token client | session | Customer | Not confirmed | Not confirmed | 2026-10-16 |
Availability depends on your product, plan and agreement. See the documentation below for the requirements of each route.
ECONOMIC ACCESS
Cost, authentication and limits
Lowest-paid-plan entitlement and complete fixed API or partner access fees are unresolved.
Check API entitlement, credential ownership and rate limits for the route you intend to use. Include review fees, customer-plan upgrades and ongoing access charges in the total.
ACT FROM OUTSIDE
External action
POST /Employees creates an employee; PATCH /Employees/{XRefCode} updates HR fields and permitted subresources. isValidateOnly checks validation without saving; omitted and null fields differ.
Validate the supported operation, acting identity and permission scope (read access does not imply write permission). Ambiguous retries and revoked credentials also affect whether an external workflow can run safely.
KEEP ACCESS USEFUL
Continuity
Poll paired update windows, fetch every returned XRefCode’s details, then advance the window only after that group completes. Effective-date changes also matter. Updated employee identities are documented. Employee persistence and termination/status changes do not establish a hard-deletion stream or erased payload recovery. Repeat unfiltered XRefCode enumeration and every permitted detail request at a declared ContextDate to rebuild current-as-of scoped HR records. Full history and deleted payloads are excluded. The client-level guide gives employee-detail capacity as 10 XRefCodes/second or 100/minute, depending on operation; heavier operations can be lower. Queue denials and complete each ID group before starting the next.
CDC, deletions and recovery
| Question | Answer / applicable route | Evidence |
|---|---|---|
| Can ongoing extraction identify updates and deleted records on the declared route? | Updates identified; deletion capture not establishedDayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Updated employee identities are documented. Employee persistence and termination/status changes do not establish a hard-deletion stream or erased payload recovery. | Dayforce employee identifier enumeration ↗Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective recordsChecked 2026-10-16 Dayforce add employee REST service ↗POST /Employees; validation; employees persist and cannot be removed by this serviceChecked 2026-10-16 |
| How can extraction recover after missed events or an interrupted consumer? | Rebuild from a fresh snapshot; no historical replay establishedDayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Repeat unfiltered XRefCode enumeration and every permitted detail request at a declared ContextDate to rebuild current-as-of scoped HR records. Full history and deleted payloads are excluded. | Dayforce employee identifier enumeration ↗Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective recordsChecked 2026-10-16 Dayforce current employee HR details ↗One XRefCode per request; ContextDate and Expand; current effective selection rather than complete historyChecked 2026-10-16 |
Useful ongoing access includes corrections and deletions, not only the first export. A failed request, changed filter or lost resource permission should not be interpreted as a deleted record.
LEAVE WITH YOUR DATA
Data exit and portability
The declared current record collection is portable; full history, files, configuration and whole-product reconstruction are unverified. Live retrieval does not establish contractual access after cancellation.
Test the output against the destination’s required fields and history. Check stable identifiers, relationships, attachments and extraction time; a sample file proves only the coverage of that sample.
BUILD / INSPECT / REUSE
Business logic and customization
The documented route supports external integration code; native workflow authoring and portability are unverified (API clients are separate artifacts). Rights to reusable native workflow definitions and independent execution are unresolved.
Custom API access, ownership of workflows and the right to export their definitions are separate questions. A custom-app capability alone does not establish that business rules can move to another system.
AGREEMENTS / API DOCS / PROGRAM REQUIREMENTS
Documented conditions
Answers below come from public provider materials. Every answer retains its source check date, scope (a partner agreement does not describe every customer route). Customer contracts and live behavior still need verification.
| Question | Answer / applicable route | Evidence |
|---|---|---|
| What structured read interface is documented? | Structured API for the declared product scopeDayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Unfiltered employee enumeration returns XRefCodes; fetch each permitted employee detail using ContextDate and selected Expand subresources. The current-as-of response is not full employee history. | Dayforce employee identifier enumeration ↗Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective recordsChecked 2026-10-16 |
| How can customers retrieve data in bulk? | Batched or iterable API requestsDayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Enumerate all employee XRefCodes without update filters, then retrieve details for each ID with fixed ContextDate/Expand and permissions. This is iterable scoped retrieval, not a database dump. | Dayforce employee identifier enumeration ↗Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective recordsChecked 2026-10-16 Dayforce current employee HR details ↗One XRefCode per request; ContextDate and Expand; current effective selection rather than complete historyChecked 2026-10-16 |
| What queries can a customer issue outside the provider UI? | Documented structured API filtersDayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Employee ID discovery supports paired update start/end filters, including changes in effective records. ContextDate and Expand control detail selection. | Dayforce employee identifier enumeration ↗Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective recordsChecked 2026-10-16 |
| Who decides whether a chosen third party may connect? | -Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Customer administrators configure Web Services users and roles. The reviewed technical guides do not establish whether a chosen third-party provider needs a separate commercial agreement. | Dayforce REST authentication ↗Web Services login credentials and default-role requirementChecked 2026-10-16 Dayforce Web Services role configuration ↗Enable Web Services on user role; field authorization separateChecked 2026-10-16 |
| What extra commercial condition applies to the routes supplying the assessed read capability, relative to the lowest paid plan? | -Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Lowest-paid-plan entitlement and complete fixed API or partner access fees are unresolved. | Dayforce REST authentication ↗Web Services login credentials and default-role requirementChecked 2026-10-16 |
| What permission is needed for the documented downstream use? | -Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. The operation guides do not establish applicable downstream processing, AI-use or redistribution rights. | Dayforce REST authentication ↗Web Services login credentials and default-role requirementChecked 2026-10-16 |
| Which external write operations are documented? | Create and update in one business domainDayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. POST /Employees creates an employee; PATCH /Employees/{XRefCode} updates HR fields and permitted subresources. isValidateOnly checks validation without saving; omitted and null fields differ. | Dayforce add employee REST service ↗POST /Employees; validation; employees persist and cannot be removed by this serviceChecked 2026-10-16 Dayforce update employee REST service ↗PATCH /Employees/{XRefCode}; null versus omitted fields; isValidateOnly; ProcessResult validationChecked 2026-10-16 |
| How can customers connect an application they build or choose? | -Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Customer credential setup alone does not establish chosen third-party production eligibility. | Dayforce REST authentication ↗Web Services login credentials and default-role requirementChecked 2026-10-16 Dayforce Web Services role configuration ↗Enable Web Services on user role; field authorization separateChecked 2026-10-16 |
| What mechanism supports repeatable extraction of changes? | Documented updated-since filters or webhooksDayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Poll paired update windows, fetch every returned XRefCode’s details, then advance the window only after that group completes. Effective-date changes also matter. | Dayforce employee identifier enumeration ↗Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective recordsChecked 2026-10-16 |
| How are integration limits disclosed? | Published numeric quotas and recovery instructionsDayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. The client-level guide gives employee-detail capacity as 10 XRefCodes/second or 100/minute, depending on operation; heavier operations can be lower. Queue denials and complete each ID group before starting the next. | Dayforce REST limits and request ordering ↗Client-level allocation; employee detail example 10 XRefCodes/second or 100/minute; queue and sequential window completionChecked 2026-10-16 |
| Where can a usable data copy be delivered? | Customer-held structured files or API recordsDayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Permitted structured API records can form a customer-held copy. | Dayforce employee identifier enumeration ↗Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective recordsChecked 2026-10-16 |
| What retrieval rights are documented at cancellation? | -Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Live retrieval does not establish contractual access after cancellation. | Dayforce employee identifier enumeration ↗Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective recordsChecked 2026-10-16 |
| How can customers define their own business logic? | External integration code; native business logic portability not establishedDayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. The documented route supports external integration code; native workflow authoring and portability are unverified (API clients are separate artifacts). | Dayforce REST authentication ↗Web Services login credentials and default-role requirementChecked 2026-10-16 |
| What rights or portability are documented for custom workflow artifacts? | -Dayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. Rights to reusable native workflow definitions and independent execution are unresolved. | Dayforce REST authentication ↗Web Services login credentials and default-role requirementChecked 2026-10-16 |
| What usable data or native definitions can leave before cancellation? | Portable structured records on documented routes; whole-product completeness unverifiedDayforce / REST employee HR identities and permitted current-as-of employee details, plus employee create/PATCH under Web Services roles. Reports, payroll execution, full effective-dated history and other product APIs are separate. The declared current record collection is portable; full history, files, configuration and whole-product reconstruction are unverified. | Dayforce employee identifier enumeration ↗Unfiltered Get Employees returns all IDs; both FilterUpdatedStartDate/EndDate; changed and effective recordsChecked 2026-10-16 |
SOURCES / SCOPE / HISTORY
Sources and open questions
This review is based on the documentation below. Live account behavior and customer-specific agreements haven’t been tested.
Still to confirm
- Chosen third-party eligibility and provider selection requirements
- Complete lowest-plan entitlement and fixed API fees
- Applicable downstream processing, AI-use and redistribution rights
- Eligibility for a chosen custom application
- Contractual post-cancellation retrieval terms
- Native workflow artifact ownership, reusable export and independent execution
Documentation
Assessment checked 2026-10-16. Each answer retains its source and applicable route; the check date does not establish live account behavior.