> ## Documentation Index
> Fetch the complete documentation index at: https://www.composer.id/llms.txt
> Use this file to discover all available pages before exploring further.
# Ceridian Dayforce
> Ceridian Dayforce (HRIS / HCM): the API posture, publish target and field mapping composerID publishes a decision reference through.
This page records how composerID publishes into Ceridian Dayforce: the vendor's API posture, the publish target and field mapping, and the documentation each claim rests on. It is for anyone evaluating the connection or building against it.
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.
Category: HRIS / HCM. Coverage status: Carrier mapped. Vendor documentation: public developer portal.
## Integration path
How composerID connects to this destination, at a glance.
| Step | Detail |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 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). |
| composerID publishes | Position: Positions resource (POST /Positions, then GET /Positions/\{xRefCode} and PATCH /Positions/\{xRefCode}) |
| Intent ID lands on | `Position` `XRefCode`, written into the destination record |
| Carrier evidence | Cited: the vendor documents this field on this object. Source: [Dayforce REST developer guide: POST Position data](https://help.dayforce.com/r/documents/Dayforce-RESTful-Web-Services-Developer-Guide/POST-Position-Data), checked 23 September 2026. |
| Back-sync | Polling: the destination publishes no events composerID can subscribe to, so state is read back on a schedule. |
## Vendor documentation
## API posture
| Aspect | Detail |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 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. |
| 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](http://www.dayforcehcm.com); test, config and stage environments live on their own regional hosts; clientNamespace is the tenant's namespace) |
| 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. |
| Events posture | Polling |
| 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. |
| Objects | Employees (XRefCode, WorkAssignments, EmploymentStatuses, Addresses, Contacts, EmployeeProperties), Positions, Jobs, Departments, OrgUnits, Locations, PayClasses, Reports, Documents, JobPostings and JobPostingApplicants (Recruiting), TimeAwayFromWork |
## Publish target and field mapping
Each object below pairs the canonical intent fields with the destination's own fields and operations. The mapping is indicative until it is confirmed against a tenant at onboarding.
| Mapping | Detail |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Canonical to destination | role\_title (ShortName / LongName), job (Job.XRefCode), department (Department.XRefCode), effective\_date (EffectiveStart) |
| Target | Positions resource (POST /Positions, then GET /Positions/\{xRefCode} and PATCH /Positions/\{xRefCode}) |
| Requirement | Required |
| Notes | 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 |
| Mapping | Detail |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Canonical to destination | intent\_id -> Position.XRefCode |
| Target | XRefCode on the Position record (the client-supplied cross-reference that is also the GET / PATCH path key) |
| Requirement | Required |
| Notes | 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) |
| Mapping | Detail |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Canonical to destination | candidate -> Employee.XRefCode, WorkAssignments\[].Position.XRefCode = the Intent-carrying Position, hire\_date |
| Target | Employees resource (POST /Employees, PATCH /Employees/\{xRefCode}) |
| Requirement | Recommended |
| Notes | 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 |
| Mapping | Detail |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Canonical to destination | employees updated since, position filled, employment status changes |
| Target | GET /Employees?filterUpdatedStartDate=...\&filterUpdatedEndDate=... then GET /Employees/\{xRefCode}?expand=WorkAssignments,EmploymentStatuses; GET /Reports/\{xRefCode} for bulk |
| Requirement | Read scope only |
| Notes | 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 |
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.
## Next steps
The five ways composerID reaches a destination, and the minimum a destination must offer.
Plan, preflight and publish: how a decision becomes a valid record in a destination.
Every destination composerID documents, with its category and coverage status.