Ceridian Dayforce

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, 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

Dayforce Developer Network (portal root)

API Explorer (endpoint reference by resource and release)

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; 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.

Position

Open the approved headcount

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

Intent ID correlation

Carry the Intent ID

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)

Employee (new hire)

Close the loop on the hire

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

Change read-back

Poll for what executed

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

How composerID connects

The five ways composerID reaches a destination, and the minimum a destination must offer.

Publishing

Plan, preflight and publish: how a decision becomes a valid record in a destination.

All destinations

Every destination composerID documents, with its category and coverage status.

⌘I

Get started

Concepts

Guides

Destinations

Upstream connectors

API reference

Endpoints

Manuscript API (Triage)

Manuscript endpoints

Resources

Integration path

Vendor documentation

Dayforce Developer Network (portal root)

API Explorer (endpoint reference by resource and release)

API posture

Publish target and field mapping

Next steps

How composerID connects

Publishing

All destinations

​Integration path

​Vendor documentation

Dayforce Developer Network (portal root)

API Explorer (endpoint reference by resource and release)

​API posture

​Publish target and field mapping

​Next steps

How composerID connects

Publishing

All destinations

Integration path

Vendor documentation

API posture

Publish target and field mapping

Next steps