How to extract custom report data from Workday using Reports as a Service (RaaS)

Key takeaways

• RaaS turns a Workday custom report into a URL you can call from outside the tenant. Standard reports have to be copied first.
• It is read only. Writing back to Workday needs SOAP or REST.
• The data you get back is scoped by the security of the account making the call, usually an ISU, and the report has to be shared with that account.
• JSON is the practical default. Add date prompts to the report so each call returns only what changed.
• Long, unbounded reports hit execution and size limits. For large or code-controlled extracts, WQL is often the better fit.

Workday will happily turn a custom report into a URL you can call from outside the tenant. That part takes an afternoon.

What takes longer is discovering, months in, which reports qualify, which format your integration actually wants, what the report is allowed to return to your integration, and which limits you're about to hit.

Reports as a Service (RaaS) exposes a Workday custom report as a web service. Call its URL with valid credentials and Workday returns the report's data instead of a rendered page. That's the whole mechanism. The work is in the setup, the security, the URL and prompts, and knowing when RaaS is the wrong tool. For how RaaS compares with SOAP and REST overall, see Workday REST vs SOAP vs RaaS.

What Reports as a Service is

RaaS takes a report you've already built in Workday and makes it callable. Point an HTTP client at the report's URL and Workday hands back the rows as JSON, CSV or one of several XML formats. It's the same report your HR team runs by hand, reachable from another system.

Not every report qualifies. Only custom reports can be enabled as a web service, typically of the Advanced type. Workday's delivered standard reports can't be exposed directly. If a standard report already has what you need, copy it into a custom report and enable the copy.

RaaS is often the easiest way to reach custom and calculated fields a customer has built in their tenant, because the report writer can pull them directly. If Workday's integration options are new to you, our primer on Workday integrations shows where RaaS fits.

Setting up the report, web service and security

1. Create or copy the report. Build an Advanced custom report with the fields you need, or copy a standard report into one.
2. Enable it as a web service. In the report definition, turn on the option to enable it as a web service.
3. Add prompts for incremental pulls. A date prompt, such as an "updated from" date, lets each call ask only for what changed since the last run.
4. Share it with the integration's account. On the report's Share tab, add the ISU as an authorized user. A report that isn't shared with the caller fails, however good the credentials are.
5. Copy the URL. From the report's Related Actions, go to Web Service > View URLs and copy the URL for the format you want.

Bindbee's Workday RaaS setup guide walks through the same steps with screenshots, including registering an API client if you want OAuth instead of basic auth. If you still need the ISU itself, start with our ISU provisioning guide.

Choosing an output format

JSON is the default for a reason: RFC 8259 made it the standard for system-to-system data exchange, and almost every modern client parses it natively. CSV earns its place for file loads, but its quoting and encoding still vary between tools despite RFC 4180, which is why Workday offers the bom=true flag for Excel.

Building the RaaS URL

Every RaaS endpoint has the same anatomy:

# Copy the base URL from the report: Related Actions > Web Service > View URLs > JSON.
curl "https://{host}/ccx/service/customreport2/{tenant}/{report_owner}/{report_name}?Updated_From=2026-09-20&format=json" \
  -u "{isu_username}:{isu_password}"

# Or authenticate with an OAuth 2.0 bearer token instead of basic auth:
#   -H "Authorization: Bearer {access_token}"

A report built with a prompt exposes it as a query parameter. Pass a date and the report returns only the matching records, which is what keeps a nightly pull small:

import os
import requests
from datetime import date, timedelta

BASE = ("https://{host}/ccx/service/customreport2/"
        "{tenant}/{report_owner}/{report_name}")

def pull_changes(since: date) -> list[dict]:
    params = {
        "Updated_From": since.isoformat(),  # a prompt you defined in the report
        "format": "json",
    }
    resp = requests.get(
        BASE,
        params=params,
        auth=(os.environ["WORKDAY_ISU_USERNAME"], os.environ["WORKDAY_ISU_PASSWORD"]),
        timeout=1800,  # long reports can run for many minutes
    )
    resp.raise_for_status()
    # JSON output wraps rows in "Report_Entry"
    return resp.json().get("Report_Entry", [])

rows = pull_changes(date.today() - timedelta(days=1))
print(f"{len(rows)} changed rows")

A RaaS request is a GET, which RFC 9110 defines as a safe method. Polling on a schedule or retrying a failed pull can't write anything back to the tenant. If you're working over SOAP instead, take the report's WSDL from the same View URLs page.

Security, and what silently breaks a working setup

Two different accounts appear in a RaaS call, and mixing them up causes most of the confusion:

• The report owner in the URL identifies the report definition.
• The caller, usually an Integration System User, is who the request authenticates as. The report must be shared with it, and its security groups decide which rows and fields it can see.

Things that break a working setup, usually without warning:

• The report isn't shared with the ISU, or was unshared during a cleanup.
• The ISU's security groups lack a domain the report's fields depend on, so columns come back empty.
• A tenant refresh or ownership change alters the owner segment, so the URL your integration calls no longer matches.
• Someone edits the report. A renamed field or changed filter changes your integration's input with it. The report is the contract, and nothing enforces it.

Where RaaS stops: limits, and RaaS vs WQL

RaaS returns a report in one response, so a report that tries to return a whole workforce with dozens of columns can run into execution and size limits. Microsoft's Workday integration docs, citing Workday's RaaS support article, put a single report call at up to 30 minutes of execution and about 2 GB of output. Date prompts and narrow column sets keep you well inside that.

When the job outgrows a report, WQL (Workday Query Language) is the usual alternative:

Both share the same shape, though: a batch pull against one tenant that someone has to run, monitor and re-run. If your product needs Workday data flowing continuously, and the same for every other HR system your customers use, that shape is the real limit. Unified API vs workflow ETL covers that choice more broadly.

When one report isn't the whole job

For a genuine custom-report job, RaaS is a perfectly good tool. The limits start to matter when a benefits or HR platform needs the same data from dozens of customers' Workday tenants, plus ADP, UKG and others, each with its own quirks.

A unified API handles that repetition once. Bindbee connects to Workday and 67+ other HRIS, payroll, ATS and benefits systems through one API, with 40+ unified data models. For Workday it offers both a standard connector and a dedicated RaaS connector that reads a report your customer builds and shares with their ISU, so tenant-specific custom fields reach your product in the same schema as everything else.

• Reads and writes through one API.
• Syncs every 24 hours by default, adjustable per connection, with a webhook when a sync finishes or finds changed records.
• SOC 2 Type II and ISO 27001 certified, HIPAA and GDPR compliant, with a standard BAA template negotiated for enterprise agreements.

None of this beats RaaS for a single, one-off extract. It solves a different problem: the same extraction, read and write, across many systems and tenants. See Bindbee's Workday integration or the product overview. We build the integrations. You build the product.

FAQ

Which Workday reports can be enabled as a web service?

Custom reports, typically of the Advanced type. Workday's delivered standard reports can't be enabled directly, so copy the standard report into a custom report and enable the copy.

What output formats does Workday RaaS support?

JSON, CSV, Simple XML, Workday XML, GData and RSS. JSON suits system-to-system integrations and CSV suits file loads. Workday XML also gives you an XSD and a WSDL for schema-validated consumers.

Can Workday RaaS write data back?

No. RaaS is read only. Writing to Workday requires SOAP web services or the REST API.

Why does my RaaS call return an error or no data?

Check that the report is shared with the account making the call, that the account's security groups can see the report's data, and that the report owner in the URL is still correct. A tenant refresh or a renamed report can change the URL an integration depends on.

Should I use RaaS or WQL?

Use RaaS for bounded, report-shaped extracts, especially when the data lives in custom or calculated fields a customer maintains. Use WQL when your code needs to control the query, page through large results, or run the same extract across tenants.