.png)
Dayforce Integration Guide
Integrate Dayforce HCM with enterprise applications through OAuth 2.0-secured REST APIs, scheduled workflows, data mapping, and controlled API façades.
Dayforce integration options at a glance
Dayforce HCM primarily supports REST APIs for accessing workforce, employee, organizational, scheduling, time, and payroll-related data. These APIs use OAuth 2.0 and tenant- or data-center-specific configuration. General-purpose webhooks are not confirmed, so scheduled polling with effective-date or change-tracking filters may be required. Some legacy or product-specific SOAP and batch capabilities may exist, but they should be verified before use. Martini can authenticate to Dayforce, paginate and checkpoint REST responses, transform JSON, apply business rules, synchronize target systems, and expose a controlled REST API for downstream consumers.
| Integration point | Supported by Dayforce? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Access Employees, Employment Assignments, Jobs, Locations, Organizations, Departments, Schedules, Time Away, and permitted payroll-related data. REST is the primary mechanism to evaluate for new integrations. | Martini can consume Dayforce REST endpoints, manage OAuth access tokens, paginate responses, transform JSON, apply business rules, and write results to target applications or databases. |
| Authentication | Yes | Dayforce integrations use OAuth 2.0 client registration, client credentials, access tokens, scopes or roles, tenant configuration, and data-center-specific API settings. | Martini can keep client credentials, scopes, base URLs, and environment-specific authorization configuration in protected configuration and secrets, then use the resulting token in workflows. |
| SOAP APIs | Limited | Historical or product-specific Dayforce web-service capabilities may be available for established implementations, but REST should be preferred for new work unless a required function is SOAP-only. | Martini can consume SOAP services when the customer confirms a supported Dayforce service and provides its contract and authentication requirements. |
| Bulk, asynchronous, and batch APIs | Limited | Dayforce has integration-oriented and high-volume capabilities in some contexts, but universal bulk or asynchronous REST support across all objects was not confirmed. | Martini can implement scheduled batch workflows with pagination, bounded processing, checkpoints, staging, controlled concurrency, and retry handling without representing these patterns as a universal Dayforce bulk API. |
| Webhooks and outbound callbacks | Not confirmed | General-purpose webhook coverage for all Dayforce employees, payroll, scheduling, and time events was not confirmed. Specific product or tenant callbacks must be verified. | If a supported callback is confirmed, Martini can receive and process it; otherwise, Martini can use scheduled REST polling where the required endpoint supports incremental retrieval. |
| File and attachment APIs | Not confirmed | File exchange may be available for particular Dayforce modules or customer implementations, but no general public file or attachment API was confirmed. | Martini can process a documented file exchange when the customer confirms its format and transport, but the implementation should not assume a general Dayforce file interface. |
| Database and analytics access | No | Direct access to the Dayforce production data store is not a standard external integration mechanism and was not confirmed. | Martini should use documented Dayforce APIs or exports rather than direct database connectivity. Martini can stage API results in an approved database when required. |
How Dayforce exposes data and business events
Dayforce REST APIs
Dayforce REST APIs are the primary documented integration mechanism for programmatic access to HCM data and operations. Endpoint availability, resource fields, permissions, pagination, and base URLs depend on the customer tenant and configuration.
Martini implementation pattern
Martini implementation pattern: a workflow obtains an OAuth 2.0 access token, calls the applicable Dayforce endpoint, follows the endpoint-specific pagination model, maps the JSON response, applies business rules, and writes the result to a target system or staging store. Martini can also expose a controlled REST API that hides Dayforce-specific details.
Implementation sequence
Scheduled REST synchronization
General-purpose outbound webhooks were not confirmed for Dayforce, so scheduled retrieval is a practical pattern for employee, organizational, scheduling, time, and selected payroll synchronizations. Incremental filtering depends on the endpoint.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow that reads a stored checkpoint or effective-date window, retrieves bounded pages from Dayforce, processes each object idempotently, and stores the new checkpoint only after successful handling. Errors can be isolated for replay and reconciliation.
Implementation sequence
Dayforce SOAP services
Dayforce has historically provided web-service capabilities, but current availability is product- and implementation-specific. SOAP should be treated as a legacy option and verified in the Dayforce Developer Portal and tenant documentation.
Martini implementation pattern
Martini implementation pattern: where a required Dayforce function is only available through an established SOAP service, Martini can consume the confirmed service contract, configure the required authentication, transform XML messages, and route SOAP faults separately from business validation errors.
Implementation sequence
Batch and high-volume processing
Dayforce has integration-oriented and high-volume capabilities in some contexts, but a universal bulk or asynchronous REST API was not confirmed. High-volume designs should be based on the specific object and tenant documentation.
Martini implementation pattern
Martini implementation pattern: a scheduled workflow retrieves data in bounded pages, stages or transforms each page, controls concurrency, stores checkpoints, and retries transient failures. This is a Martini processing design and should not be described as a universal Dayforce bulk API.
Implementation sequence
Common Dayforce integration patterns
Pattern 1: Synchronize employees and organizational data
When to use this pattern
Use this pattern when Dayforce is the source for workforce identity, assignments, jobs, locations, and departments that must be aligned with another HCM, identity, finance, or service platform. It is suitable for scheduled incremental processing where the required endpoint supports effective-date or change-tracking filters.
Integration direction
Example Mapping
| Dayforce Field | Canonical Field | Target Field |
|---|---|---|
| Employee.EmployeeNumber | worker.externalId | user.employeeId |
| Employee.Status | worker.lifecycleStatus | user.accountEnabled |
| Employment Assignment.Department | organization.departmentCode | user.department |
| Location.Name | organization.locationName | user.officeLocation |
Martini implementation pattern
A scheduled workflow obtains an OAuth token, retrieves changed Employees and related objects, follows pagination, and resolves assignment and organizational relationships. Martini maps the response to a canonical workforce model, applies hire, transfer, leave, rehire, and termination rules, performs idempotent target upserts, and stores checkpoints. Transient failures are retried while permission, validation, and mapping errors are sent to reconciliation.
Martini capabilities used
- workflows
- API consumption
- OAuth 2.0 configuration
- data mapping
- business rules
- checkpointing
- error handling
Pattern 2: Provision and deprovision workforce identities
When to use this pattern
Use this pattern when Dayforce employee status or employment information drives identity creation, attribute updates, suspension, or deactivation in an identity platform. The workflow should explicitly distinguish new hires, transfers, leave states, terminations, and rehires.
Integration direction
Example Mapping
| Dayforce Field | Canonical Field | Target Field |
|---|---|---|
| Employee.EmployeeNumber | identity.sourceId | profile.employeeNumber |
| Employee.Email | identity.email | profile.email |
| Employee.Status | identity.lifecycleStatus | active |
| Employment Assignment.Job | identity.jobCode | profile.title |
Martini implementation pattern
Martini polls the relevant Dayforce resources on a controlled schedule, classifies lifecycle changes, validates mandatory identity fields, and invokes Okta APIs. Stable source IDs and create-or-update behavior prevent duplicates. The workflow applies least-privilege field selection and routes malformed data or target policy conflicts for review instead of repeatedly retrying them.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- conditional routing
- business rules
- idempotency
- error handling
Pattern 3: Synchronize time away and schedules
When to use this pattern
Use this pattern when approved absence, leave, or schedule information in Dayforce must be delivered to payroll, project accounting, workforce planning, or reporting applications. Effective dates, date ranges, and approval status should be validated before publication.
Integration direction
Example Mapping
| Dayforce Field | Canonical Field | Target Field |
|---|---|---|
| Time Away.Employee | absence.workerId | employee.externalId |
| Time Away.StartDate | absence.startDate | timeOff.startDate |
| Time Away.EndDate | absence.endDate | timeOff.endDate |
| Time Away.Status | absence.approvalStatus | timeOff.status |
Martini implementation pattern
A scheduled Martini workflow retrieves Schedules or Time Away data using supported filters, validates approval and date-range rules, maps employee and organizational identifiers, and submits only eligible records to the target API. Idempotent keys prevent duplicate time entries, while rejected records and transient failures are separated for replay.
Martini capabilities used
- scheduler trigger
- API consumption
- JSON handling
- mapping and transformation
- validation
- business rules
- retry handling
Pattern 4: Exchange permitted payroll data with finance
When to use this pattern
Use this pattern when approved Pay Details or payroll-related data must be transferred to a finance platform. It is appropriate only when the Dayforce tenant, roles, regional configuration, and endpoint permissions support the required data.
Integration direction
Example Mapping
| Dayforce Field | Canonical Field | Target Field |
|---|---|---|
| Pay Details.Employee | payroll.workerId | employeeId |
| Pay Details.Department | payroll.costCenter | costCenter |
| Pay Details.PayPeriod | payroll.period | postingPeriod |
| Pay Details.Amount | payroll.amount | amount |
Martini implementation pattern
Martini retrieves the minimum permitted payroll fields, validates period and approval conditions, maps departments and locations to finance dimensions, and sends the transformed payload to SAP S/4HANA. Secrets remain in protected environment configuration, sensitive values are excluded from logs, and financial validation failures are reconciled separately from transport failures.
Martini capabilities used
- workflows
- OAuth 2.0 configuration
- data minimization
- data mapping
- validation
- secure configuration
- reconciliation
Applications commonly integrated with Dayforce
Dayforce can be integrated with adjacent workforce, identity, service-management, CRM, finance, and enterprise platforms. These scenarios depend on the target product APIs and the Dayforce objects, permissions, and tenant configuration available to the customer.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Workday | Exchange worker, organization, job, or payroll-related information where an organization operates more than one HCM platform. | Dayforce → Martini → Workday | A scheduled Martini workflow retrieves permitted Dayforce Employees, Employment Assignments, Jobs, and organizational data, applies source-of-truth rules, and upserts the corresponding Workday objects through Workday APIs. Checkpoints, effective dates, and reconciliation results help manage overlap between systems. |
| Okta | Provision, update, or deactivate workforce identities based on employee lifecycle changes in Dayforce. | Dayforce → Martini → Okta | Martini polls relevant Dayforce employee and employment resources, classifies hires, transfers, leave states, and terminations, then invokes Okta APIs with idempotent user identifiers. Permission failures and invalid lifecycle states are routed for review rather than blindly retried. |
| Microsoft Entra ID | Synchronize employee attributes and employment status with directory accounts and access-management processes. | Dayforce → Martini → Microsoft Entra ID | A scheduled workflow maps Dayforce employee, assignment, department, location, and status values to Microsoft Entra ID user attributes. Martini applies lifecycle rules, minimizes transmitted personal data, and records checkpoints for replay and reconciliation. |
| ServiceNow | Create or update onboarding, offboarding, employee-related service records, and access requests from workforce lifecycle changes. | Dayforce → Martini → ServiceNow | Martini retrieves changed Dayforce Employees and Employment Assignments, evaluates lifecycle and organizational rules, and calls ServiceNow APIs to create or update tasks and records. Stable source identifiers prevent duplicate requests during retries. |
| Salesforce | Keep employee, territory, user, or organizational information aligned where workforce data affects CRM ownership and operations. | Dayforce → Martini → Salesforce | Martini transforms Dayforce employee and organizational data into Salesforce user, territory, or ownership-related models, applies field-level business rules, and performs controlled upserts. Validation errors are separated from transient API failures for targeted remediation. |
| NetSuite | Transfer approved payroll, labor-cost, department, location, or employee-related accounting data to finance. | Dayforce → Martini → NetSuite | A Martini workflow retrieves permitted Dayforce Pay Details or payroll-related data, validates period and approval status, maps departments and locations to NetSuite dimensions, and submits the result through NetSuite APIs. Sensitive fields are minimized and financial failures are reconciled. |
| SAP S/4HANA | Exchange employee, organizational, cost-center, payroll, or accounting information in larger enterprise landscapes. | Dayforce → Martini → SAP S/4HANA | Martini orchestrates Dayforce REST calls and SAP S/4HANA API operations, using a canonical workforce model for organizational and cost-center mappings. Effective dates, duplicate prevention, and staged retries support reliable bidirectional processing. |
| Jira | Create onboarding, offboarding, or HR operations tasks from Dayforce worker lifecycle changes. | Dayforce → Martini → Jira | A scheduled Martini workflow identifies relevant Dayforce status or assignment changes, applies task-creation rules, and invokes Jira APIs with source identifiers and mapped due dates. Duplicate detection and a replay path support operational recovery. |
How to build a Dayforce integration in Martini
Objective
Establish tenant-specific Dayforce connectivity using the customer’s authorization service, API base URL, OAuth client registration, scopes, roles, and environment configuration.
Instructions in Martini
- Register the integration client in the Dayforce environment
- Store client credentials, scopes, tenant values, and URLs in protected Martini configuration
- Use HTTPS and least-privilege Dayforce permissions
- Separate development, test, and production settings
Objective
Select scheduled polling for resources without confirmed general-purpose callbacks, or use a documented callback only when the specific Dayforce product, event, and tenant capability are confirmed.
Instructions in Martini
- Use a scheduler for employee, assignment, organizational, schedule, or time synchronization
- Define an effective-date, last-modified, or comparison strategy when supported
- Confirm any Dayforce callback or event capability before relying on it
Objective
Call the required Dayforce REST resources and retrieve bounded, appropriately filtered data while preserving source identifiers and effective dates.
Instructions in Martini
- Request an OAuth access token before calling protected resources
- Follow each endpoint’s pagination and query semantics
- Capture stable identifiers, status values, timestamps, and effective dates
- Use staging or checkpoints for larger populations
Objective
Coordinate resource retrieval, related-object lookups, transformation, target writes, and operational state within a maintainable Martini workflow.
Instructions in Martini
- Sequence dependent Employees, Assignments, Jobs, Locations, and Departments operations
- Use conditional routing for lifecycle and approval states
- Separate independent record failures where appropriate
- Persist checkpoints only after successful processing
Objective
Convert Dayforce JSON and effective-dated workforce data into the target application’s model without losing identifiers, dates, or relevant status distinctions.
Instructions in Martini
- Create explicit mappings for source and target identifiers
- Normalize dates, status values, departments, locations, and job codes
- Preserve effective dates and distinguish current from future changes
- Validate required fields and configured enumerations
Objective
Apply customer-specific rules for hires, transfers, leave, terminations, rehires, multiple assignments, approval states, and sensitive payroll fields.
Instructions in Martini
- Define source-of-truth rules for overlapping HCM platforms
- Filter payroll and personal data to the required fields
- Apply target-specific create, update, suspend, or deactivate behavior
- Route validation and policy exceptions for review
Common Dayforce data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Employees | Synchronize worker identity, employment status, contact information, work assignment, and personnel attributes. | Okta, Microsoft Entra ID, ServiceNow, Salesforce, Workday | Martini retrieves permitted employee data, applies effective-date and lifecycle rules, maps JSON fields, and upserts using stable Dayforce identifiers with checkpointing. |
| Employment Assignments | Represent employment relationships, assignments, effective dates, and organizational placement. | Workday, SAP S/4HANA, Microsoft Entra ID, ServiceNow | Martini preserves assignment identifiers and effective dates, distinguishes current and future changes, and applies rules for transfers, multiple relationships, rehires, and terminations. |
| Jobs | Synchronize job definitions, job assignments, and job-related worker attributes. | Workday, Salesforce, SAP S/4HANA | Martini maps job codes and attributes to target models, validates configured values, and routes unmapped or invalid job data for review. |
| Locations | Align physical or organizational work locations across workforce, identity, finance, and service systems. | Microsoft Entra ID, Salesforce, NetSuite, SAP S/4HANA | Martini normalizes location identifiers and names, applies target-specific mappings, and handles changes idempotently. |
| Organizations / Departments | Synchronize organizational units, reporting structures, departments, and cost-related classifications. | SAP S/4HANA, NetSuite, Salesforce, ServiceNow | Martini maps department and organization hierarchies through a canonical model, preserves effective dates, and validates target references before writing. |
| Pay Details / Payroll Data | Transfer permitted compensation, pay-related, payroll, labor-cost, or accounting information. | NetSuite, SAP S/4HANA, Workday | Martini limits fields to the approved scope, validates period and status rules, protects sensitive values, and records reconciliation outcomes without exposing payroll data in logs. |
Authentication and security considerations
OAuth 2.0 and tenant configuration
Dayforce REST integrations require an OAuth 2.0 client registration, client ID, client secret, access token, required scopes or roles, and tenant- or data-center-specific API configuration. The exact authorization service and base URL depend on the customer environment.
Protect workforce data
- Store client credentials, tokens, scopes, and tenant settings in protected Martini environment configuration.
- Use least-privilege Dayforce permissions and separate development, test, and production credentials.
- Use HTTPS and minimize employee, payroll, compensation, tax, absence, and contact data sent to targets.
- Restrict logs and avoid recording OAuth secrets or complete sensitive employee payloads.
Operational considerations for Dayforce integrations
Reliable synchronization
- Confirm pagination, page-size, continuation, filtering, and rate-limit behavior for each Dayforce endpoint.
- Use effective dates, supported last-modified filters, or stored checkpoints instead of repeatedly retrieving the full population.
- Use stable Dayforce identifiers and target external IDs to make writes idempotent.
- Apply exponential backoff to transient failures and throttling responses; do not blindly retry permission or validation errors.
Data and schema controls
- Preserve effective dates and distinguish current, future-dated, retroactive, and historical changes.
- Expect fields, enum values, organizational structures, pay codes, and object availability to vary by module, region, role, and tenant configuration.
- Separate transport, authentication, permission, validation, and business-rule errors.
- Maintain reconciliation reports, replay paths, and source-to-target count checks after scheduled runs.
Why use Martini instead of scripts or point-to-point integrations?
Beyond point-to-point scripts
Martini provides a maintainable workflow layer around Dayforce REST APIs, rather than embedding authentication, pagination, mapping, and retry logic in isolated scripts. Workflows can coordinate related Dayforce resources, target applications, staging stores, and business rules in one observable integration asset.
Controlled and reusable integration behavior
- Keep tenant-specific endpoints and OAuth settings in environment configuration.
- Reuse mappings, validation, error handling, and checkpoint patterns across workforce integrations.
- Expose a stable REST API façade when downstream applications should not depend directly on Dayforce details.
- Support scheduled, batch-oriented, and API-led processing with monitoring and reconciliation.
Frequently asked questions
Dayforce is primarily integrated through its REST APIs, which provide programmatic access to HCM data and operations. Integrations use OAuth 2.0, tenant-specific API configuration, JSON mapping, pagination, and scheduled synchronization where event delivery is not available. Historical or product-specific SOAP services and selected batch capabilities should be verified for the relevant tenant before use.
Yes. Martini can consume Dayforce REST APIs using OAuth 2.0, transform Employees and other Dayforce objects, apply business rules, and synchronize target applications or databases. Martini can also expose a controlled REST API façade. General-purpose Dayforce webhook coverage is not confirmed, so scheduled polling may be required.
No. A dedicated Dayforce connector is not required. Martini can integrate with Dayforce using its confirmed native REST APIs and OAuth 2.0 authentication, and can use a specific SOAP service or callback when that capability is documented and enabled for the customer’s use case.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Dayforce. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Dayforce, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
REST APIs should be the starting point for new Dayforce integrations. OAuth 2.0 is required for API access, while endpoint-specific pagination, filtering, permissions, and tenant configuration must be confirmed. SOAP is a legacy or product-specific option, and universal GraphQL support was not confirmed.
General-purpose webhook coverage for every employee, payroll, scheduling, or time event was not confirmed. A specific Dayforce product or tenant may provide an event-oriented capability, but it must be verified. Where no suitable callback exists, Martini can use scheduled REST polling with supported effective-date or change-tracking filters.
Martini can run scheduled workflows that retrieve bounded pages, use effective dates or supported incremental filters, map data to a canonical or target model, and upsert using stable Dayforce identifiers. Checkpoints, idempotency, reconciliation reports, and targeted retries help prevent duplicates and support recovery from partial failures.
Yes. Martini can expose a REST API that invokes workflows, calls Dayforce, applies authorization and business rules, and returns a controlled response to downstream applications. This can keep tenant-specific URLs, OAuth details, and Dayforce object structures behind a stable enterprise-facing interface.
Related Martini documentation
API Integration
Workflows
Data Processing
Connect Dayforce with Martini
Use Martini to build secure, maintainable Dayforce integrations for workforce data synchronization, identity lifecycle automation, time and absence processing, and finance data exchange.