Ceridian Dayforce (platform)
Dayforce (formerly Ceridian Dayforce) is a single-database HCM covering HR, payroll, workforce management, talent and recruiting, with a REST API served from the tenant's own host under /Api/{clientNamespace}/V1. Every Dayforce record carries a client-supplied XRefCode that is also its path key, so an external identifier round-trips without a custom field. composerID publishes an approved permanent-hire decision as a Position whose XRefCode is the Intent ID, then reads the eventual Employee record back through the work assignment that references that Position.
The public API facts composerID's adapter relies on. Tenant-specific details (custom fields, picklists, approval chains) are confirmed during connection and folded into the MappingProfile.
| Authentication | HTTP Basic with a dedicated Dayforce web services user is the documented baseline: the user's role must hold Web Services access plus a per-resource feature grant (role Features > Web Services). OAuth 2.0 client credentials issued by Dayforce Identity is documented for newer releases; which of the two the tenant permits is confirmed at onboarding. |
|---|---|
| API style | REST, JSON; versioned path segment (V1) whose resources and request bodies track the tenant's Dayforce release. Collection reads return XRefCodes; detail reads are per record by XRefCode, with an expand parameter for child collections. |
| Base URL | https://{host}/Api/{clientNamespace}/V1/{resource} (production host www.dayforcehcm.com; test, config and stage environments live on their own regional hosts; clientNamespace is the tenant's namespace) |
| Objects | Employees (XRefCode, WorkAssignments, EmploymentStatuses, Addresses, Contacts, EmployeeProperties), Positions, Jobs, Departments, OrgUnits, Locations, PayClasses, Reports, Documents, JobPostings and JobPostingApplicants (Recruiting), TimeAwayFromWork |
| Events / webhooks | No general-purpose webhook mechanism is documented in the public API Explorer: reads are pull-based, using filterUpdatedStartDate / filterUpdatedEndDate on Employees and saved Reports run by XRefCode for bulk change capture. Newer releases advertise event-driven options through Dayforce integration tooling; indicative until confirmed at onboarding. |
| Rate limits | No numeric ceiling is published on the developer portal. Dayforce asks integrations to page collection reads and fetch detail per XRefCode rather than in bulk; treat any limit as indicative until confirmed at onboarding. |
“Docs confidence” describes how deterministic our mapping templates can be before we connect to a tenant. Even with public docs, implementations vary, especially around custom fields, approval flows and object extensions.
Deterministic mapping
Common Workforce Model fields map to known API fields. Best for standard objects (requisitions, assignments, timesheets, POs).
Tenant discovery
composerID can scan tenant configuration (custom fields, picklists, required fields) where the platform permits it, then generate a tenant‑specific MappingProfile.
Enrichment loop
If the target platform requires a field the Intent record doesn't yet have, composerID emits an enrichment_request back to the intake layer.
An opinionated baseline. The platform adapter enforces additional requirements via preflight. “Tenant required” fields are discovered during connection and added to the MappingProfile.
| Object | Canonical fields | Platform target | Required status | Notes |
|---|---|---|---|---|
| Position Open the approved headcount |
role_title (ShortName / LongName), job (Job.XRefCode), department (Department.XRefCode), effective_date (EffectiveStart) | Positions resource (POST /Positions, then GET /Positions/{xRefCode} and PATCH /Positions/{xRefCode}) | Required | A Dayforce Position is a Job plus Department pairing; pay class and location belong to the employee's work assignment, not the Position. Position write support and the exact request body vary by Dayforce release and by the web services role's feature grants; confirm create access in the tenant before treating this as the publish path |
| Intent ID correlation Carry the Intent ID |
intent_id -> Position.XRefCode | XRefCode on the Position record (the client-supplied cross-reference that is also the GET / PATCH path key) | Required | XRefCode is stock on every Dayforce record, unique per object type within a tenant and readable back by key, so no custom field is needed. Confirm the tenant's XRefCode maximum length for Positions against the 64-character Intent ID at onboarding; if it is shorter, fall back to an Employee Property (user-defined field) on the hire. UI deep link https://{tenant_host}/MyDayforce/#/positions/{external_id} (illustrative) |
| Employee (new hire) Close the loop on the hire |
candidate -> Employee.XRefCode, WorkAssignments[].Position.XRefCode = the Intent-carrying Position, hire_date | Employees resource (POST /Employees, PATCH /Employees/{xRefCode}) | Recommended | The hired employee's work assignment references the Position, which ties the person's HR record back to the Intent ID without a second stamp |
| Change read-back Poll for what executed |
employees updated since, position filled, employment status changes | GET /Employees?filterUpdatedStartDate=...&filterUpdatedEndDate=... then GET /Employees/{xRefCode}?expand=WorkAssignments,EmploymentStatuses; GET /Reports/{xRefCode} for bulk | Read scope only | No webhooks: composerID polls on the updated-date window (which returns XRefCodes only), fetches detail per record, and runs a saved Report by XRefCode for bulk reconciliation |
Idempotency & drift: publish + reconcileExpand
Publish operations are idempotent using a deterministic key {intent_id}-{intent_version}-{target_system}. Because humans can change records inside the platform, composerID supports reconciliation: it compares the platform record snapshot to the canonical intent and flags drift.
Real deployments rely on program-specific custom fields (for compliance, approvals, GL coding, rate rules or supplier constraints). composerID is designed to generate tenant‑specific mappings rather than forcing you to redesign your intake.
How scanning works
High-level flow
What gets produced
Portable artefacts
Important: where this platform is tenant-definedExpand
Every call needs a dedicated web services user whose role grants Web Services access and the specific feature for each resource (role Features > Web Services): a role that reads Employees does not automatically write Positions. The API surface tracks the tenant's Dayforce release, so Position create support, endpoint availability and request bodies are confirmed against the tenant's version in the API Explorer, not the portal's latest. Only the tenant can confirm its XRefCode length limit for Positions against the Intent ID, whether it exposes OAuth 2.0 client credentials or HTTP Basic only, and which saved Report (if any) is set up for bulk read-back. Test, config and stage environments sit on their own regional hosts with separate credentials and namespaces.
Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.