Ellipse Gradient for Header
Workday Extend logo

Workday Extend Integration Guide

Connect Workday Extend applications and Workday business objects with enterprise systems through REST APIs, SOAP web services, reports, files, and selected event interfaces.

Workday Extend integration options at a glance

Workday Extend applications operate within the Workday ecosystem and can use Workday business objects, security policies, business processes, and APIs. Workday provides versioned REST APIs for selected functional areas and SOAP Web Services for many established domains. Reports-as-a-Service, extracts, file exchanges, and selected asynchronous operations support scheduled and bulk-oriented synchronization. Event and callback mechanisms are available only for particular products and scenarios. Martini can consume these interfaces, process JSON, XML, CSV, and spreadsheet outputs, expose controlled REST APIs, map Workday data to downstream systems, and orchestrate retries, checkpoints, and business rules.

Integration pointSupported by Workday Extend?Common use casesHow Martini supports it
REST APIsYesVersioned REST APIs support selected Workday functional areas, including retrieval and supported creation or update operations for objects such as Workers, Organizations, Positions, and Applicants.Martini can consume Workday REST endpoints, handle pagination and asynchronous responses where documented, transform payloads, and expose a stable API façade.
SOAP APIsYesWorkday Web Services provide versioned SOAP operations across many established domains and complex business-process interfaces.Martini can consume Workday SOAP services, construct XML requests, parse namespaces and responses, and route SOAP faults through workflow error handling.
Report-based accessYesReports-as-a-Service and report extracts provide controlled XML, JSON, or CSV outputs for read-oriented synchronization and operational data feeds.Martini can invoke or receive report outputs, process files or response payloads, apply prompts and checkpoints, and map extract fields to target systems.
Webhooks / outbound callbacksLimitedSelected Workday products and integration scenarios provide event notifications, callbacks, or outbound integration actions; coverage is not universal across objects or events.Martini can expose a REST endpoint or start-trigger workflow for a confirmed callback and can correlate the notification with a subsequent Workday retrieval.
Bulk / async / batch processingLimitedWorkday supports scheduled extracts, pagination, integration-system patterns, and selected asynchronous operations, but does not provide one universal bulk API for every object.Martini can schedule pages or files, persist checkpoints, poll documented status operations, and process large datasets in restartable batches.
File / attachment exchangeLimitedFile, document, report, and attachment capabilities are available in selected Workday services and integration configurations.Martini can process Workday-supported JSON, XML, CSV, and spreadsheet files and orchestrate delivery when the target Workday interface supports the exchange.
AuthenticationYesWorkday integrations commonly use OAuth 2.0 with tenant-specific scopes or an Integration System User with security groups and domain permissions. Some interfaces may support Basic Authentication.Martini can externalize tenant URLs, credentials, tokens, and environment settings through secure configuration and use the authentication method required by the Workday interface.
Database / analytics accessLimitedWorkday provides reports, extracts, and selected analytics interfaces, but direct SQL access to the underlying Workday production database is not a standard integration method.Martini can consume documented reports, files, APIs, and analytics interfaces; it should not be designed around direct Workday database connectivity.

How Workday Extend exposes data and business events

Workday REST APIs

Workday provides versioned REST APIs for selected functional areas. Available resources, fields, operations, and API versions depend on the Workday release, licensed products, tenant configuration, and security permissions.

Martini implementation pattern

Martini implementation pattern: A Martini workflow authenticates with the configured Workday OAuth client or approved integration identity, retrieves or submits REST resources, handles pagination or asynchronous status where documented, maps the response, and writes the result to the target system or returns it through a Martini API.

Implementation sequence

Authenticate to the configured Workday tenant
Retrieve or submit the documented REST resource
Handle pagination or asynchronous completion when required
Validate and map the Workday payload
Write the result and persist a checkpoint or correlation identifier

Workday SOAP Web Services

Workday Web Services expose versioned SOAP APIs across many established domains. SOAP is particularly relevant where the required capability is mature, complex, or not available through a suitable REST resource.

Martini implementation pattern

Martini implementation pattern: A workflow uses the tenant-specific WSDL and security configuration, builds the XML request, invokes the SOAP operation, parses the response or SOAP fault, and transforms the result for downstream processing.

Implementation sequence

Select the tenant-supported WSDL and operation
Authenticate with the configured Workday integration identity
Build the namespaced XML request
Invoke the SOAP service and inspect faults
Map the XML response and record the operation outcome

Workday Reports and Extracts

Workday reports can provide XML, JSON, or CSV outputs for controlled, read-oriented synchronization. Reports and extracts are useful for scheduled feeds and large datasets but should not be treated as general-purpose CRUD APIs.

Martini implementation pattern

Martini implementation pattern: A scheduled workflow requests or receives the approved report output, parses the selected format, applies prompt and checkpoint logic, validates rows or objects, and loads the target system in restartable batches.

Implementation sequence

Start the scheduled extract workflow
Request or receive the configured report output
Parse the XML, JSON, or CSV content
Apply prompts, change windows, and validation rules
Load target records and store the extract checkpoint

Workday Callbacks and Events

Workday supports selected event, callback, and outbound integration mechanisms, including product-specific business-process notifications. Availability depends on the Workday product, event type, tenant configuration, and interface.

Martini implementation pattern

Martini implementation pattern: Where a specific callback is documented, Martini exposes a protected endpoint or start-trigger workflow, validates the notification, retrieves authoritative Workday data, and updates the target. If no supported event exists, the same workflow can be initiated by a schedule or status query.

Implementation sequence

Confirm the specific Workday event or callback contract
Receive the notification through a protected Martini endpoint
Validate the event and extract its correlation data
Retrieve authoritative Workday details when necessary
Apply business rules and update the target idempotently

Workday Files and Attachments

Workday provides file, document, report, and attachment capabilities for selected services and integration configurations. Support and payload semantics are functional-area-specific.

Martini implementation pattern

Martini implementation pattern: A workflow receives or retrieves the supported file, identifies the Workday functional context, parses the content, validates the batch, and delivers or stores the transformed result while retaining file and correlation metadata.

Implementation sequence

Identify the supported Workday file or attachment interface
Retrieve or receive the file content
Parse and validate the file format
Transform rows or documents for the target system
Record the file identifier, batch result, and exceptions

Common Workday Extend integration patterns

Pattern 1: Synchronize Workers to an identity platform

When to use this pattern

Use this pattern when Worker lifecycle changes in Workday must drive account provisioning, updates, or deprovisioning in Microsoft Entra ID or Okta. The source may be a REST or SOAP interface, a report extract, or a confirmed event mechanism.

Integration direction
Workday Extend
Martini
Microsoft Entra ID
Example Mapping
Workday Extend FieldCanonical FieldTarget Field
Worker.workerReferenceworkerIdemployeeId
Worker.emailAddressworkEmailuserPrincipalName
Worker.workerStatusemploymentStatusaccountEnabled
Worker.supervisoryOrganizationmanagerOrganizationdepartment
Martini implementation pattern

A scheduled or event-triggered Martini workflow retrieves changed Workers, resolves effective-dated and termination conditions, validates required identity attributes, and performs idempotent upserts. Stable Workday identifiers and checkpoints prevent duplicate provisioning; transient failures are retried with backoff and rejected records are routed for review.

Martini capabilities used
  • workflows
  • API consumption
  • scheduling
  • data mapping
  • business rules
  • error handling

Pattern 2: Synchronize recruiting data to downstream applications

When to use this pattern

Use this pattern when Job Requisitions, Applicants, Positions, or related recruiting data must be shared with Salesforce, Snowflake, or another approved recruiting and analytics application. The exact objects and operations must be available in the tenant’s Recruiting APIs or reports.

Integration direction
Workday Extend
Martini
Salesforce
Example Mapping
Workday Extend FieldCanonical FieldTarget Field
JobRequisition.requisitionReferencerequisitionIdexternalRequisitionId
JobRequisition.statusrequisitionStatusstatus
JobRequisition.jobProfilejobProfilejobTitle
JobRequisition.organizationowningOrganizationdepartment
Martini implementation pattern

Martini retrieves the approved recruiting resource or report, filters by requisition status and organization, normalizes Workday-specific references, and writes target objects. The workflow records source identifiers and batch checkpoints, validates required fields, and retries rate or transport failures without recreating successful target records.

Martini capabilities used
  • workflows
  • API consumption
  • report processing
  • data transformation
  • validation
  • retry handling

Pattern 3: Expose a controlled Workday data API façade

When to use this pattern

Use this pattern when multiple downstream applications need Worker, Organization, Position, or other Workday data but should not each manage Workday credentials, schemas, and API versions.

Integration direction
Consumer application
Martini
Workday Extend
Example Mapping
Workday Extend FieldCanonical FieldTarget Field
Worker.workerReferencepersonIdconsumer.personId
Worker.legalNamedisplayNameconsumer.displayName
Worker.workerStatusstatusconsumer.status
Organization.organizationReferenceorganizationIdconsumer.organizationId
Martini implementation pattern

Martini exposes a controlled REST API, authenticates to Workday from secure environment configuration, retrieves only the authorized data, applies field filtering and stable transformations, and returns an organization-specific schema. Validation, authorization, correlation logging, and upstream error translation isolate consumers from Workday-specific changes.

Martini capabilities used
  • API exposure
  • API consumption
  • authentication and authorization
  • data mapping
  • business rules
  • error handling

Pattern 4: Orchestrate a Workday business process

When to use this pattern

Use this pattern when an external application must initiate a documented Workday hire, change job, approval, or related business-process operation and receive a meaningful status outcome.

Integration direction
External application
Martini
Workday Extend
Example Mapping
Workday Extend FieldCanonical FieldTarget Field
request.externalReferencecorrelationIdWorkday request reference
request.workerIdworkerIdWorkday Worker reference
request.effectiveDateeffectiveDatebusiness process effective date
Workday.processStatusprocessStatusexternal request status
Martini implementation pattern

A Martini API or workflow validates the external request, applies authorization and effective-date rules, invokes the documented REST or SOAP operation, and stores the Workday request or process identifier. The workflow polls a documented status operation or receives a supported callback, distinguishes pending from completed or rejected states, and uses correlation data for retries and duplicate prevention.

Martini capabilities used
  • API exposure
  • workflows
  • SOAP and REST consumption
  • validation
  • business rules
  • correlation and error handling

Applications commonly integrated with Workday Extend

Workday Extend integration requirements commonly arise when Workday data must support identity, employee service, recruiting, finance, or analytics processes in adjacent applications. The exact objects, fields, and direction depend on the Workday tenant, licensed products, and the system designated as authoritative.

Application Scenario Direction Martini Pattern
Microsoft Entra ID Synchronize Worker identity, department, manager, and employment-status data for joiner, mover, and leaver processes. Workday Extend → Martini → Microsoft Entra ID Run a scheduled or supported event-driven workflow, retrieve changed Workers through REST, SOAP, or a report extract, apply termination and effective-date rules, and perform idempotent provisioning updates.
Okta Automate identity lifecycle processes using Workday Worker and organizational information. Workday Extend → Martini → Okta Use a checkpointed Martini workflow to normalize Worker identifiers, status, manager, and organizational fields before calling Okta APIs and recording provisioning outcomes.
Salesforce Synchronize employee, organizational, account-team, or territory information and support selected HR-related service workflows. Workday Extend → Martini → Salesforce Expose or schedule a Martini workflow that retrieves approved Workday objects, maps them to Salesforce fields, validates required values, and routes rejected updates for review.
ServiceNow Create or update onboarding, access, employee-service, or integration-exception activities from Workday changes. Workday Extend → Martini → ServiceNow Transform Worker and Organization changes into ServiceNow requests or tasks, retain Workday correlation identifiers, and optionally send approved requests back through a controlled Martini API.
Jira Create work items for onboarding, HR operations, or exceptions generated from Workday extracts and approved events. Workday Extend → Martini → Jira Filter Workday events or scheduled results by business rule, map them to Jira project and issue fields, and use durable correlation data to avoid duplicate issues.
SAP SuccessFactors Exchange Worker, Organization, recruiting, or talent information where both platforms coexist across business units or transition programs. Workday Extend → Martini → SAP SuccessFactors Implement object-specific bidirectional workflows with an explicit system-of-record rule, effective-date handling, conflict detection, and retryable API or file exchanges.
NetSuite Synchronize employee, department, cost-center, supplier, or finance-related reference information where the platforms share business data. Workday Extend → Martini → NetSuite Use scheduled Workday reports or APIs, map organization and reference identifiers to NetSuite structures, validate accounting dimensions, and persist processing checkpoints.
Snowflake Load Worker, Organization, recruiting, or financial extracts into an analytical data platform without direct access to the Workday application database. Workday Extend → Martini → Snowflake Retrieve approved reports, files, or API pages, parse and normalize the results, apply schema validation, and load staged data with batch identifiers and restartable processing.

How to build a Workday Extend integration in Martini

Objective

Establish tenant-specific access using the Workday authentication method and permissions required by the selected interface.

Instructions in Martini

  • Choose OAuth 2.0 or an approved Integration System User configuration based on the Workday API.
  • Store tenant identifiers, URLs, credentials, scopes, and tokens in secure Martini configuration.
  • Confirm Workday domain security, security groups, and business-process permissions.

Objective

Select a trigger that matches the Workday capability and synchronization latency requirements.

Instructions in Martini

  • Use a scheduled workflow for reports, extracts, polling, and incremental synchronization.
  • Use a start trigger or protected API endpoint only for a specifically documented Workday callback or event.
  • Define a checkpoint, effective-date window, or correlation strategy before processing data.

Objective

Consume the appropriate Workday interface and obtain authoritative source data.

Instructions in Martini

  • Call the documented REST resource or SOAP operation, or retrieve the approved report or file output.
  • Handle pagination, large responses, asynchronous status, and format-specific parsing.
  • Capture Workday identifiers, API versions, batch identifiers, and source timestamps.

Objective

Coordinate calls, validation, enrichment, routing, and target-system operations in a maintainable Martini workflow.

Instructions in Martini

  • Separate source retrieval, normalization, business rules, target writes, and status handling into clear workflow stages.
  • Use correlation identifiers across Workday requests, callbacks, and target updates.
  • Route unsupported, incomplete, or permission-related responses to an operational exception path.

Objective

Convert Workday-specific structures into a canonical model and target application schema.

Instructions in Martini

  • Map actual Workday objects such as Worker, Organization, Position, and Business Process to target fields.
  • Normalize dates, effective dates, identifiers, status values, namespaces, and XML or report formats.
  • Apply field-level filtering for sensitive HR and recruiting data.

Objective

Enforce business and synchronization rules before changing downstream systems or initiating Workday processes.

Instructions in Martini

  • Handle effective dating, termination, approval status, duplicate detection, and system-of-record decisions.
  • Validate required references and reject records that cannot be safely processed.
  • Prevent duplicate creates and repeated business-process submissions with stable identifiers and checkpoints.

Common Workday Extend data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
WorkerSynchronize employee and contingent-worker identity, employment status, staffing, organization, and manager information.Microsoft Entra ID, Okta, ServiceNow, Salesforce, SnowflakeMartini retrieves current or changed Workers through REST, SOAP, or reports, applies effective-date and termination rules, and performs idempotent target updates.
PositionExchange position details, restrictions, organizational placement, and staffing requirements.Salesforce, SAP SuccessFactors, Snowflake, recruiting applicationsMartini maps position identifiers and organizational references, validates status and effective dates, and routes unsupported or incomplete changes for review.
Job RequisitionSynchronize recruiting requisition status, job profile, organization, location, and recruiting workflow data.Salesforce, Snowflake, recruiting and job-board applicationsMartini retrieves supported recruiting data through the tenant’s available API or report, filters by status and organization, and normalizes the result for downstream consumers.
OrganizationShare companies, cost centers, regions, and other organizational structures used for reporting and routing.NetSuite, Salesforce, ServiceNow, SnowflakeMartini resolves organization identifiers, maps hierarchy and type fields, and applies system-of-record rules before publishing changes.
Supervisory OrganizationRepresent management hierarchy for staffing, reporting, approvals, and business-process routing.Microsoft Entra ID, Okta, ServiceNow, SnowflakeMartini preserves hierarchy relationships, handles effective-dated changes, and prevents incomplete parent references from being propagated.
Business ProcessRepresent configured Workday processes such as hire, change job, compensation change, absence, and approval workflows.ServiceNow, Salesforce, internal employee applicationsMartini submits documented operations, records request or process identifiers, and distinguishes accepted, pending, completed, rejected, canceled, and rescinded states.

Authentication and security considerations

Tenant-scoped authentication

Workday integrations commonly use OAuth 2.0 with tenant-specific scopes or an Integration System User with security groups and domain permissions. Some interfaces may support Basic Authentication, but it should be treated as API- and tenant-specific.

Authorization is separate from authentication

A valid token or ISU login does not guarantee access to a Worker, Business Process, report, or operation. Workday administrators must configure API scopes, domain security policies, security groups, and business-process permissions.

Protect sensitive HR data

  • Store tenant URLs, client credentials, tokens, and environment settings in secure Martini configuration.
  • Limit Worker, compensation, absence, and recruiting fields to the minimum required.
  • Restrict logs and diagnostics so that sensitive personal information is not unnecessarily recorded.

Operational considerations for Workday Extend integrations

Tenant and release variation

Workday API versions, fields, operations, reports, and event interfaces vary by tenant, release, licensed product, and security configuration. Confirm the target interface before implementation and test against the actual tenant.

Pagination, throttling, and retries

Use bounded concurrency, pagination, staged file processing, and checkpoints for large datasets. Apply backoff for transient failures and avoid aggressive polling because limits can differ between REST, SOAP, reports, and integration-system interfaces.

Business-process status

A successful submission may only mean that a Workday process was accepted or initiated. Persist request identifiers and distinguish pending, completed, rejected, canceled, and rescinded states through documented callbacks or status operations.

Idempotency and schema evolution

Use stable Workday identifiers, external references, correlation IDs, and durable checkpoints to prevent duplicate creates or repeated submissions. Validate schemas and avoid undocumented fields because Workday releases can introduce new versions, fields, deprecated operations, or changed business rules.

Why use Martini instead of scripts or point-to-point integrations?

Orchestrate more than one API call

Workday integrations often combine authentication, object retrieval, report processing, validation, business-process submission, status checks, and downstream updates. Martini coordinates these activities in workflows instead of scattering logic across scripts.

Maintain clear mappings and rules

Martini provides reusable mapping, transformation, validation, and business-rule stages for Workday JSON, XML, CSV, and spreadsheet outputs. This makes effective dating, organizational hierarchies, status values, and sensitive-field filtering explicit and maintainable.

Operate integrations reliably

Checkpoints, correlation identifiers, controlled retries, error paths, monitoring, and secure configuration support restartable synchronization. Martini can also expose a stable API façade so downstream applications do not each implement Workday authentication and schema handling.

Frequently asked questions

How can Workday Extend be integrated with enterprise systems?

Workday Extend integrations can use Workday versioned REST APIs, SOAP Web Services, report-based XML, JSON, or CSV extracts, selected file interfaces, and product-specific event or callback mechanisms. The exact interface depends on the Workday tenant, licensed products, API version, security configuration, and target business capability.

Can Martini integrate with Workday Extend?

Yes. Martini can integrate with Workday Extend and Workday business objects by consuming confirmed Workday REST APIs, SOAP Web Services, reports, files, and selected callbacks or event interfaces. Martini can orchestrate workflows, map data, expose APIs, and handle checkpoints and errors.

Do I need a connector to integrate Workday Extend with Martini?

No. A dedicated Workday Extend connector is not required. Martini can use Workday’s confirmed native integration mechanisms, including REST, SOAP, report and file interfaces, authentication methods, and selected callbacks or events.

Is there any extra Lonti cost to integrate Workday Extend with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Workday Extend with Martini. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Workday, cloud infrastructure, or other third-party services based on licensing, usage, and deployment configuration.

Should a new Workday integration use REST or SOAP?

Use the interface documented for the required Workday capability and available in the target tenant. REST is suitable for supported resource-oriented operations, while SOAP remains important for many established domains and complex operations. API coverage, permissions, operation semantics, and tenant availability should determine the choice.

Can Martini receive Workday webhook events or callbacks?

Only for a specific Workday product or integration scenario that provides a documented callback or event mechanism. Coverage is not universal across Workday business objects, so scheduled REST, SOAP, report, or status-polling workflows may be required instead.

How does synchronization handle Workday changes and effective dates?

Martini can use the source interface’s supported change-detection method, such as updated timestamps, report prompts, effective-date windows, event identifiers, or integration identifiers. Durable checkpoints, stable Workday identifiers, idempotent updates, and explicit handling for future-dated, corrected, rescinded, and terminated records are important.

Can Martini expose an API façade for Workday Extend?

Yes. Martini can expose a controlled REST API that retrieves authorized Workday data, applies field filtering and transformation, and returns an organization-specific schema. This can reduce the number of downstream systems that require direct Workday credentials and isolate consumers from Workday-specific structures.

Related Martini documentation

Workday APIs

Workflows

Data Processing

Security

Operations

Connect Workday Extend with your enterprise systems

Use Martini to implement secure, maintainable Workday Extend integrations across APIs, SOAP services, reports, files, callbacks, and downstream applications.

EXPLORE MARTINI
BOOK A DEMO