Key takeaways

• RaaS is for scheduled, read-only extracts of specific fields. It can't write anything back to Workday.
• SOAP (Workday Web Services) is the default for high-volume or bidirectional sync. It has the broadest coverage and most write operations.
• REST is for small, low-latency transactions where the object you need is already published as REST.
• Whichever you pick, pull only what changed since the last run, or every sync grows with headcount.
• The method is the easy half. Mapping Workday's data into your own model is the work that repeats for every customer.

Workday REST API vs SOAP vs RaaS:

Workday exposes the same HR data through three different doors: a SOAP web services layer, a REST API, and Reports as a Service. Most guides treat picking one as the whole decision. It isn't.

Get it wrong and the failure shows up on two different timelines. Pick RaaS for a job that needs to write back to Workday, and you find the gap at go-live, not in planning. Pick SOAP for a one-off scheduled read, and you've committed to maintaining a versioned XML contract for something a report and a JSON feed would have handled.

This page compares the three, shows what a real request looks like on each, and closes with the part that outlasts whichever one you pick: mapping Workday's data into your own model. If you're after authentication and security details instead, read our Workday API authentication guide.

The three ways Workday exposes HR data

• SOAP, or Workday Web Services (WWS): the original surface. Broad coverage, read and write, and a versioned XML contract.
• REST: JSON over HTTP, secured per endpoint, covering a narrower slice of objects.
• RaaS: a custom Workday report exposed as a web service. Flexible about which fields it returns, and read only.

There's a fourth option you'll see mentioned, WQL (Workday Query Language). It's built for querying and reporting rather than system-to-system integration, so it isn't compared here.

SOAP: the enterprise workhorse

SOAP has been Workday's primary integration surface the longest, and it covers more of the platform's core operations than REST. That's why most enterprise Workday integrations, including the ones that write data back, still run on it.

Each service ships with a WSDL, an XML contract that spells out every operation and what it expects, and tooling can generate a client straight from it. Each endpoint also carries a version in its URL, so you pick the version you build against and upgrade when you're ready. The cost is that new fields and operations only arrive in newer versions, and old versions are eventually retired, so upgrades belong on the roadmap.

The feature that matters most for sync jobs is changed-records-only pulls. Requests like Get_Workers accept a transaction date range, so a nightly job asks for what changed since the last run instead of the whole workforce:

POST https://{host}/ccx/service/{tenant}/Human_Resources/v{version}
Content-Type: text/xml; charset=UTF-8

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:bsvc="urn:com.workday/bsvc">
  <soapenv:Header>
    <!-- WS-Security header with ISU credentials goes here -->
  </soapenv:Header>
  <soapenv:Body>
    <bsvc:Get_Workers_Request bsvc:version="v{version}">
      <bsvc:Request_Criteria>
        <bsvc:Transaction_Log_Criteria_Data>
          <bsvc:Transaction_Date_Range_Data>
            <bsvc:Updated_From>2026-09-20T00:00:00Z</bsvc:Updated_From>
            <bsvc:Updated_Through>2026-09-21T00:00:00Z</bsvc:Updated_Through>
          </bsvc:Transaction_Date_Range_Data>
        </bsvc:Transaction_Log_Criteria_Data>
      </bsvc:Request_Criteria>
      <bsvc:Response_Filter>
        <bsvc:Page>1</bsvc:Page>
        <bsvc:Count>100</bsvc:Count>
      </bsvc:Response_Filter>
      <bsvc:Response_Group>
        <bsvc:Include_Personal_Information>true</bsvc:Include_Personal_Information>
        <bsvc:Include_Employment_Information>true</bsvc:Include_Employment_Information>
      </bsvc:Response_Group>
    </bsvc:Get_Workers_Request>
  </soapenv:Body>
</soapenv:Envelope>

<!-- Check element names against the WSDL version you pin. -->

For a full end-to-end example, see pulling employee data from Workday SOAP with Python. If SOAP is new to your team, start with SOAP for REST developers.

REST: modern, JSON, narrower coverage

Where SOAP hands you a WSDL and an XML envelope, Workday's REST API is JSON over HTTP. It's lighter to parse and closer to what most teams build against every day. Every endpoint is secured individually, so access can be scoped tightly to exactly the operation you need.

curl "https://{host}/ccx/api/v1/{tenant}/workers?limit=100&offset=0" \
  -H "Authorization: Bearer {access_token}"

# Increase offset by limit until the response returns fewer records than limit.

The gap teams miss is coverage. REST only covers what Workday has published as REST, which is still a subset of what SOAP can do. If the object you need is there and the job is a small, low-latency transaction, REST is the better fit by a wide margin. If it isn't there, REST's simplicity doesn't help you. Check the REST directory for your exact objects before you commit, and see our Workday API overview for the wider map.

RaaS: read-only report extracts

With RaaS, you build a report inside Workday using its report writer, enable it as a web service, and call its URL on a schedule. It's the fastest way to get a specific, well-shaped slice of data out, because you design the shape yourself, including calculated and tenant-specific fields that are awkward to reach through SOAP.

# Copy the base URL from the report: Web Service > View URLs > JSON.
# "Updated_From" is an example prompt name. Prompts are whatever you define in the report.
curl "https://{host}/ccx/service/customreport2/{tenant}/{report_owner}/{report_name}?Updated_From=2026-09-20&format=json" \
  -u "{isu_username}:{isu_password}"

RaaS reads. It doesn't write. Updating an address, a benefit election or a termination date still requires SOAP or REST. Teams that miss this find out when a workflow needs to push a change back and there's nowhere for RaaS to put it.

RaaS can return JSON, CSV, Simple XML, Workday XML, RSS or GData. Two things make it fragile in practice:

• The report is the contract. If someone at the customer edits the report, renames a field or changes its filters, every integration built on it changes with it.
• Big reports hit limits. A report that tries to return the whole workforce in one call can run into execution and size limits. Microsoft's Workday integration docs cite a 30-minute execution limit and about 2 GB of output per call. Date prompts keep each call small.

Bindbee supports this path through a separate Workday RaaS connector, alongside the standard Workday connector.

The three methods, side by side

Two operational points apply to all three. First, Workday enforces tenant-level request limits and timeouts that vary by tenant, and publishes them in its Community documentation, so pull the numbers for your tenant rather than trusting any blog, this one included. Second, a request pattern that ran fine against a 3,000-person test tenant can throttle against a 30,000-person production one. Incremental pulls, paging and backoff on throttling are what keep the method you picked working at full size.

How to choose

The decision comes down to two questions. Does the job need to write back to Workday? Does it need to run at volume on a schedule? Answer those and the method mostly picks itself:

Pick correctly here and you've solved the transport problem. What you haven't solved yet is what happens to the data once it lands.

The method is the easy half: mapping Workday to your model

Every method above answers the same question: how do bytes move between Workday and your system. None of them answers the question your product actually needs answered. What does "dependent" mean in your data model? What does a mid-year plan change look like once it lands? What happens when a termination has to reach three downstream systems instead of one?

A team that builds the cleanest possible SOAP integration still has to decide how a Workday worker, position, job profile and compensation plan map onto whatever your platform stores. Get the transport perfect and that mapping is still unbuilt. It's also work you redo, close to from scratch, for every customer whose Workday tenant is configured slightly differently from the last.

This is the layer a unified API is built to absorb. Bindbee connects to Workday and 67+ other HRIS, payroll, ATS and benefits systems through one API, reading and writing through the same models:

• Benefits-ready models. Employees, employments, dependents, benefits, employer benefits, dependent benefits, benefit coverages, and payroll runs with their deductions arrive in one schema, whichever system they came from.
• Custom Fields. Where a customer's tenant has a field the unified model doesn't carry, you map it with a JMESPath expression instead of waiting on a schema change.
• Both Workday paths. A standard Workday connector and a separate RaaS connector, for tenants that keep key data in reports.
• Write-back through the same API.

Bindbee's Workday connector authenticates as an ISU your customer creates, following a published setup guide, so every call stays inside Workday's own security. Syncs run every 24 hours by default, adjustable per connection, and Bindbee sends a webhook when a sync finishes or finds changed records. Benefits platforms including Newfront and Papershift run on it today.

None of this is necessary if the job really is a one-off, read-only pull from a single Workday tenant with no downstream mapping. A scheduled RaaS report, called directly, is the entire integration in that case. The layer above the method earns its cost when there's more than one customer's Workday to connect, or a benefits model on the other end that has to make sense of what arrives.

We build the integrations. You build the product. See Bindbee's Workday connector.

FAQ

Is Workday RaaS read-only?

Yes. RaaS exposes a custom report as a web service for pulling data out of Workday. It has no write path, so anything that pushes a change back into Workday has to go through SOAP or REST.

What's the difference between Workday SOAP and REST APIs?

SOAP (Workday Web Services) is the broad, versioned XML surface that covers most core operations and most write paths. REST is a JSON surface that covers a narrower set of objects and suits small, low-latency calls. Many production integrations use SOAP for sync and REST for interactive lookups.

Can Workday return only the records that changed?

Yes for SOAP, through transaction log criteria on requests such as Get_Workers, and for RaaS if the report has date prompts. Support on REST depends on the endpoint. Changed-records-only pulls keep a nightly sync proportional to what changed rather than to total headcount.

Should I use Workday RaaS or SOAP for a benefits integration?

Use SOAP when you need broad coverage or write-back, such as deductions and elections. Add RaaS when a customer's tenant keeps important data in custom or calculated fields that are easier to pull through a report. Many benefits integrations run both.

What limits apply to Workday API integrations?

Workday enforces tenant-level request limits and execution timeouts that vary by tenant, and publishes them in its Community documentation. For RaaS, Microsoft's Workday integration docs cite a 30-minute execution limit and about 2 GB of output per report call. Design large pulls to be incremental and paged either way.