How to integrate with Workday in 2026.

What workday integration actually means

If you Google “Workday integration”, the top results blur together. Vendor pages from iPaaS providers, Workday’s own marketing, HR consulting blogs, and integration-platform comparisons all treat “Workday integration” as a single problem with a single shape. It isn’t.

Workday is a sprawling enterprise platform that sits at the center of an organization’s people, finance, and operations data. Companies integrate with Workday for at least six structurally different reasons, and each reason demands a different integration approach, a different set of APIs, a different complexity budget, and frequently a different team to build and operate it.

Picking the wrong path is the most common mistake. A team that needs a jobs feed for their recruiting product spins up Workday Studio. A team that needs payroll sync uses a unified-API platform that doesn’t cover the payroll surface. A team that needs read-only career-page data negotiates an OAuth2 onboarding for every customer one by one. Six months later, everyone is unhappy.

This guide categorizes the six types of Workday integration, walks through what each requires technically, names the tools that actually fit each slice, and ends with a decision matrix you can run through in ten minutes.

The 6 types of Workday integration

Before we get into specifics, here’s the high-level shape of each integration type, in rough order of how often we see teams attempting them.

Notice that the tool choice varies wildly across types. There is no single “Workday integration platform” that handles all of these well. Vendors that claim to are usually best at one or two and weak at the others.

Type 1: HRIS / people-data sync

The most common Workday integration request: pull employee records (name, title, manager, department, location, status) from Workday into another system - usually a CRM, an HR analytics platform, an internal data warehouse, or a tool that needs an org-chart view.

API surface: Workday REST API for modern tenants (Staffing endpoints: workers, organizations, supervisoryOrganizations) or Public Web Services SOAP for deeper data. Both require OAuth2 client credentials issued per-tenant.

What makes it hard: Workday’s data model is customer-configurable. Two Workday tenants can have wildly different organizational hierarchies, custom fields, and employee statuses. A schema-mapping that works for Customer A may not for Customer B without additional configuration. Multi-tenant integration platforms (Merge.dev, Apideck) solve this by normalizing the data to a common shape across tenants - which is the right move if you’re building a SaaS that integrates with many Workday customers, and the wrong move if your one customer has very specific custom fields they need preserved exactly.

Realistic complexity: 4-8 weeks per customer if you’re doing direct OAuth2 onboarding. 1-2 days per customer if you’re using a unified API like Merge.dev (which has done the per-tenant onboarding once and gives you one connection point).

Tools that fit:

• Merge.dev - unified HRIS API covering Workday, BambooHR, ADP, Gusto, and others. One auth flow, normalized schema. Best if you integrate with multiple HRIS platforms, not just Workday.
• Apideck - similar unified API play.
• iPaaS (Workato, Boomi, Mulesoft) - traditional integration platforms with pre-built Workday connectors. Heavier setup but more flexibility for custom field mappings.
• Direct REST API - if you have one Workday customer and control of both sides, build it yourself in 4-8 weeks.

Type 2: Payroll

Payroll integration is the highest-stakes Workday integration anyone attempts. Mistakes mean people don’t get paid, which means lawsuits. Workday Payroll is configured per-country with different tax tables, pay-frequency rules, and statutory reporting requirements per region.

API surface: Workday Public Web Services SOAP (the Compensation, Payroll, Payroll_GB, Payroll_AU services). REST coverage of payroll is partial as of 2026.

What makes it hard: the SOAP envelope is verbose, multi-country requirements differ wildly, and you’re shipping to a tenant where any error has compliance consequences. Most payroll integrations also need bidirectional sync (Workday → payroll provider for gross-to-net calc, payroll provider → Workday for tax filings, pay slips, W-2s).

Realistic complexity: 3-12 months for a non-trivial integration. Often requires Workday-certified integration consultants and a Workday Studio license. Internal teams underestimate this consistently.

Tools that fit:

• Workday Cloud Connect - Workday’s prebuilt integrations with major payroll providers (ADP, Paychex, others). If your payroll target is in their catalog, this is the right answer.
• Workday Studio - in-tenant integration platform for custom payroll flows. Requires certified developers.
• iPaaS with Workday certified connectors - Workato, Boomi, and Mulesoft all have certified Workday connectors with payroll service support.

Unified-API platforms generally do not cover payroll well - Merge.dev and Apideck focus on HRIS data, not the deeper compensation and payroll surfaces.

Type 3: SSO (Single Sign-On)

The most common “Workday integration” that isn’t really an integration: SSO. Configuring Workday to authenticate through your corporate identity provider (Okta, Azure AD, OneLogin, Ping) so users don’t maintain a separate Workday password.

API surface: None, technically. SSO is configured through SAML 2.0 or OIDC metadata exchange in the Workday tenant’s admin. Both sides exchange XML certificates and endpoint URLs.

What makes it hard: not much, honestly. SAML is mature. The main gotchas are getting the Workday-side configuration right (claim mappings, NameID format, signing certificates) and handling user provisioning (SCIM 2.0 if your IdP supports it).

Realistic complexity: 2-5 days if both sides have done SAML before. Often just a few hours for Okta-to-Workday because Okta has a pre-built Workday application that handles 80% of the config.

Tools that fit: Okta, Azure AD, OneLogin, Ping Identity all have certified Workday SSO integrations. Use the IdP’s pre-built Workday app and follow Workday’s SSO documentation.

If your “Workday integration” is actually just SSO, you don’t need an integration platform, you don’t need APIs, and you don’t need a developer. You need a security admin and an afternoon.

Type 4: Recruiting / ATS sync

Pulling data from Workday Recruiting (the ATS module of Workday HCM) into or out of an external ATS or sourcing tool. Common use cases: a sourcing product that needs to see open requisitions across many companies, an external ATS migrating data into Workday, a tool that pushes candidates from LinkedIn or other channels into Workday’s pipeline.

API surface: Workday Recruiting endpoints in the Public Web Services SOAP API (Recruiting, Recruiting_Hiring services). Some REST coverage exists but it’s incomplete. The main resources: Job_Requisition, Job_Application, Candidate, Interview.

What makes it hard: Workday Recruiting is configured differently in every tenant. Custom requisition fields, custom application stages, custom approval workflows. Cross-tenant integration platforms struggle here for the same reasons HRIS sync is hard, only worse because recruiting workflows have more configuration surface area.

Realistic complexity: 6-12 weeks for one customer. Per-customer onboarding is high overhead.

Tools that fit:

• Merge.dev ATS API - covers Workday Recruiting alongside Greenhouse, Lever, Ashby, and others. One auth, normalized schema.
• Workday Recruiting CCB integration - certified partner channel for ATS-side integrations.
• Direct SOAP integration - if you need deep custom workflow access, you’ll write SOAP envelopes yourself.

Type 5: Jobs / career-data feed (this is the slice we cover)

The integration type with the most buyers and the least native Workday support: reading public job postings from Workday-hosted career sites, programmatically, across many tenants. This is what a job aggregator, a sourcing tool, an AI matching engine, or a labor-market research firm actually wants when they say “we need Workday integration.”

API surface: none, publicly. Workday does not offer a public REST endpoint that returns job postings across tenants. Each tenant hosts a career site at <tenant>.myworkdayjobs.com (or wd1.myworkdayjobs.com, wd3, wd5, etc. depending on data-center placement). The site is rendered by Workday’s UI but the underlying job data is fetched from an internal JSON endpoint that varies in shape across Workday versions.

What makes it hard:

• No tenant directory. You don’t get a list of all Workday customers - you have to discover them.
• Tenant URL placement varies (myworkdayjobs.com vs wd1 vs wd3 vs wd5). Each tenant lives in exactly one and the URL is fixed by Workday at provisioning time.
• Internal JSON endpoint structure varies between Workday versions. A parser that works for tenant A on Workday v40 may break on tenant B running v45.
• Workday’s bot detection blocks naïve scrapers. Production crawlers need rate limiting, header rotation, and graceful 429 handling.
• Some tenants disable the public career page or use a vanity custom domain that proxies Workday. Detection of these tenants is its own problem.

Realistic complexity: 4-8 engineer-weeks to build a production-grade Workday career-site crawler that handles 90% of tenants. Another 4-8 weeks to handle the long tail of edge cases. Plus ongoing maintenance every time Workday rolls out a tenant-version update that changes the internal JSON shape.

Tools that fit:

• JobsPipe - normalized Workday jobs API across 10,000+ public tenants. No per-tenant onboarding, no OAuth, no Workday version handling on your side. Free tier covers 5,000 requests/month.
• DIY scraping infrastructure - Bright Data or Apify rented infrastructure plus your own parsing layer. You own the normalization, dedup, and Workday-version handling. Reasonable if jobs scraping is your core differentiation.
• Indeed / LinkedIn syndication - both aggregate Workday postings downstream. Possible but slower (delayed by hours-to-days) and legally complicated. We recommend going upstream to the Workday tenant career page directly.

Important: this is not the Workday Recruiting API. Recruiting (Type 4) is private, OAuth’d, and per-tenant. Public career-page jobs (Type 5) are publicly accessible and the goal is multi-tenant coverage. If your buyer says “I want to read jobs from Workday customers” they mean Type 5. If they say “I want to sync our recruiting pipeline with Workday” they mean Type 4. Different problems, different APIs, different vendors.

Type 6: Custom / one-off

Everything that doesn’t fit the above five. Workday-to-NetSuite financial reconciliation. Workday-to-Salesforce attainment-data sync for sales-comp calculations. Workday-to-Microsoft-Teams notifications when a new hire’s start date is confirmed. Workday-to-Slack approval workflows for time-off requests.

API surface: whatever combination of REST, SOAP, and outbound Workday Integration Cloud connectors you need.

What makes it hard: custom integrations are custom - the difficulty depends entirely on what you’re building. The common failure mode is scope creep. A “simple Slack notification when a Workday workflow completes” turns into a six-month middleware project when you discover Workday Studio licensing requirements and certified developer dependencies.

Realistic complexity: wide variance, from a week to a year.

Tools that fit:

• iPaaS (Workato, Boomi, Mulesoft, Tray) - the default answer for “custom Workday integration”. Pre-built connectors, workflow builders, hosted operationally.
• Workday Studio + certified developer - for Workday-side orchestration that needs to live inside the tenant. Expensive and creates Workday consultant dependency.
• Direct API + custom code - if you have engineering capacity and a one-off problem, build it yourself in REST/SOAP.

The technical reality of the Workday APIs

A few things about Workday’s API surface that the marketing pages don’t emphasize.

Workday REST API

Added in Workday v32 (around 2018), the REST API is OAuth2-based and covers Staffing, Time and Absence, Compensation, and partial Recruiting. Authentication uses the client-credentials grant or authorization-code grant depending on the integration shape. Each tenant must explicitly enable REST API access and provision an API Client credential.

The REST surface keeps expanding but it does not cover everything Public Web Services SOAP covers. For new integrations, check coverage of your specific use case against the Workday Community API docs before committing.

Workday Public Web Services (SOAP)

The original Workday API surface. 50+ services covering HCM, finance, recruiting, payroll, and more. Verbose XML envelopes, WSDL-based contracts, Workday-issued client certificates for authentication. Older but more comprehensive than REST. For deep enterprise integration, expect to use SOAP whether you like it or not.

Tenant URL variants

Workday distributes tenants across data centers and the URL shape encodes the placement:

• <tenant>.myworkdayjobs.com - default career-site URL
• <tenant>.wd1.myworkdayjobs.com - data center 1
• <tenant>.wd3.myworkdayjobs.com - data center 3
• <tenant>.wd5.myworkdayjobs.com - data center 5
• <tenant>.wd12.myworkdayjobs.com - data center 12
• And so on across ~10 numbered variants

For API access, the parallel pattern is <tenant>.workday.com/ccx/api/... with the same data center prefix. Cross-tenant integrations have to maintain a tenant-to-data-center map.

OAuth2 client credentials

Setting up OAuth2 in a Workday tenant requires admin access on the Workday side. You register an Integration System User (ISU) with a specific permissions scope, generate an API Client, and exchange the resulting client_id + client_secret for access tokens. Token TTL is tenant-configurable (typically 1 hour). Refresh tokens are supported.

The catch: each tenant’s admin has to do this for your integration. For a SaaS product onboarding many Workday customers, this is the long pole. Unified API platforms (Merge.dev, Apideck) absorb this overhead by running the OAuth flows themselves.

Rate limits

The REST API publishes per-tenant rate limits (default ~1,000 req/min on Staffing endpoints) but tenants can configure their own. SOAP has no published hard limits but tenants observe degraded performance at high volumes during business hours. Production integrations should:

• Implement exponential backoff on 429 responses
• Batch large reads with proper paging (REST: ?page=N&per_page=200)
• Schedule heavy batch jobs outside the tenant’s business hours
• Monitor for HTTP 503 (tenant maintenance windows happen weekly)

Integration platforms compared

The integration platform you pick is the second-biggest decision after the integration type itself. Honest summary of what each is good at.

Workato

Modern iPaaS with a strong Workday connector. Recipe-based workflow builder, good for HR-led teams that want to build integrations without heavy developer involvement. Mid-market and enterprise pricing.

Boomi (Dell)

Long-established iPaaS with a Workday Cloud Connect-certified connector. Strong at enterprise data-integration patterns. Heavier and more enterprise-shaped than Workato. Often the default at companies with existing Dell/Boomi relationships.

Mulesoft (Salesforce)

Enterprise iPaaS bundled with Salesforce. Workday connector is mature. Strong if you’re already in Salesforce’s ecosystem and need Workday + Salesforce data unified. Expensive.

Tray.io

Modern iPaaS popular with mid-market tech companies. Cleaner developer experience than Boomi or Mulesoft. Workday support exists but check coverage for your specific use case.

Merge.dev

Unified API platform - one connection point that abstracts Workday, ADP, BambooHR, Gusto, and other HRIS providers. Best fit if you’re a SaaS building once and integrating with many HRIS customers. Doesn’t cover payroll deeply. Tiered pricing per customer connection.

Apideck

Similar shape to Merge.dev. Slightly different vertical coverage (Apideck also covers accounting, CRM, file storage). Compare both before picking.

Workday Cloud Connect

Workday’s own managed integration service. Best for prebuilt integrations to common payroll and benefits providers. If your target is in their catalog, this is usually the fastest path.

JobsPipe

Jobs-only. For Type 5 integrations (public career-data feeds across tenants), JobsPipe is the data layer. Free tier for the first 5,000 requests/month, paid plans from $49/mo. Not a Workday integration platform in the broader sense - we cover one slice deeply.

Common Workday integration gotchas

Tenant version drift

Workday rolls out semi-annual updates (R1 in March, R2 in September) and customers adopt them on different schedules. An integration tested on a Workday v45 tenant may behave differently on a v44 tenant for the same customer next quarter. Test against the customer’s actual tenant version, not just whatever’s in your sandbox.

Custom report dependency

A common pattern: your integration reads from a custom Workday report the tenant admin built specifically for the integration. Six months later, the report gets deleted or modified in a tenant cleanup and your integration silently breaks. Document custom report dependencies explicitly in the integration runbook and monitor for report-not-found errors.

SOAP API deprecation

Workday has indicated it’s gradually deprecating SOAP in favor of REST, but no firm sunset date has been announced as of 2026. Integrations that depend on SOAP services not yet covered by REST will eventually need migration. Plan accordingly.

ISU password rotation

Workday tenants often enforce password rotation on Integration System Users. If your integration uses an ISU password (legacy) rather than OAuth2 (modern), it will break every 90 days when the tenant rotates the ISU password. Switch to OAuth2.

Bot detection on career sites

If you’re reading from public career sites (Type 5), Workday deploys bot detection through Cloudflare. Naïve scrapers get blocked. Production crawlers need careful rate limiting, varied user-agent strings, and respect for robots.txt. JobsPipe handles this so consumers don’t.

OAuth scope minimalism

When negotiating OAuth scope with a tenant admin, ask for the narrowest set of permissions you actually need. Tenants are increasingly security-conscious and will push back on broad scopes. The narrower the ask, the faster the approval.

How to choose your path

Here’s the matrix we walk customers through. Answer the questions in order and you’ll land on a specific tool stack.

1. Are you reading public job postings from many Workday tenants? If yes, JobsPipe. Skip the rest of the matrix.
2. Are you syncing employee data into your own SaaS that integrates with multiple HRIS platforms? If yes, Merge.dev or Apideck.
3. Is your integration target one specific Workday customer (your own company, or a single customer you have a direct relationship with)? Build with the Workday REST API directly. Estimate 4-8 weeks per integration. Use OAuth2.
4. Is the integration payroll or deep HCM? Workday Cloud Connect if your target is in their catalog. Otherwise iPaaS (Workato, Boomi) with certified Workday connectors. Budget 3-12 months and a Workday-certified consultant.
5. Is the integration just SSO? Use the Okta / Azure AD / Ping Workday SAML pre-built app. 2-5 days. No developer required.
6. Is it “custom Workday workflow + external system notifications”? iPaaS (Workato, Tray, Mulesoft). Budget the iPaaS license plus implementation time.
7. None of the above? Custom integration. Estimate aggressively and add 50%.