When software engineers first look at integrating an AI assistant with Workday, their instinct is to wire up a handful of REST endpoints and call it done. Anyone who has spent a year configuring Workday tenants or building integrations knows why that hits a wall in the first afternoon: Workday's API surface is split across REST APIs, the Workday Graph API, Workday Query Language (WQL), Reports as a Service (RaaS), and Workday SOAP Web Services—and a large share of the administrative configuration that consultants and HRIS/Finance admins do every day is not exposed as a public mutation API in any of them.

Here is how Workday's API layers actually divide the platform, what each layer can and cannot change, and why a real Workday co-pilot has to combine API calls with visible, user-approved browser actions.

How Workday's four API layers split the work

If you are choosing an API for an integration or an Extend app (see our RaaS vs. WQL vs. REST guide), Workday's own API decision guidance separates them by role:

  1. Workday REST APIs and Workday Graph API: Built for modern interactive apps, Workday Extend pages, orchestrations, and external integrations. They expose common self-service and operational resources (workers, time off, expenses, jobs, staffing, and Extend custom business objects) with OAuth 2.0 authentication and structured JSON payloads.
  2. Workday Query Language (WQL): A fast, SQL-like read-only query interface over Workday report data sources and fields (see our WQL hub guide). WQL is the best way to read and aggregate tenant data when you know the data source and field names, but it is strictly for reading—there is no INSERT or UPDATE in WQL.
  3. Reports as a Service (RaaS): Turns any web-service-enabled Advanced, Matrix, or Simple custom report into an HTTP endpoint returning XML, JSON, or CSV. Like WQL, RaaS is read-only.
  4. Workday SOAP Web Services (urn:com.workday/bsvc): Workday's broadest transactional and bulk API surface, spanning dozens of functional services (Human_Resources, Financial_Management, Compensation, Payroll, Recruiting, Tenant_Data_Translation, and more) and powering Enterprise Interface Builder (EIB) loads and Workday Studio assemblies.

Where both REST and SOAP stop: administrative configuration

Even when you combine REST and SOAP, Workday's web services are overwhelmingly designed for transactional business data (hiring a worker, submitting an expense report, importing accounting journals, updating benefit elections) rather than meta-configuration of the tenant itself.

Consider the tasks a functional consultant or system administrator performs every week (as detailed in our guide to making Workday changes that have no API):

  • Creating or editing a chained Lookup Related Value or Extract Single Instance calculated field and testing it against specific instances.
  • Adding a step, condition rule, or Maintain Advanced Routing restriction (Exclude Initiator, Exclude Prior Approvers, Alternate Security Groups) on a business process definition.
  • Editing a custom report definition, wiring a Prompt Set, or running Validate Composite Reports and clicking Fix on a Map Fields For Join exception (see our composite report guide).
  • Adding a security group to a domain security policy and running Activate Pending Security Policy Changes.
  • Proxying as an employee, manager, and HR Partner in Sandbox to verify how a business process routes and what each persona sees on screen.

If your AI tool can only call REST or SOAP endpoints—as is true of generic API connectors—it can answer a handful of worker lookup queries, and then has to fall back to telling you which twenty clicks to make in the browser whenever you need a calculated field, a report change, a condition rule fix, or a proxy test.

Why kiweely uses the right channel for each job—with your approval

We designed kiweely so you never have to worry about whether a Workday task has a REST endpoint, a SOAP operation, a WQL data source, or only a browser task screen (see our comparison of API wrappers vs. kiweely):

  • Fast metadata and data reads where APIs and WQL shine: When inspecting data sources, verifying field values, or building and validating a Workday Extend app or Workday Studio integration, kiweely uses the direct protocol that fits the job.
  • Visible, stoppable browser execution where only the task screen exists: When a change requires configuring a calculated field, editing a business process rule, updating a report definition, or testing a workflow as multiple personas via proxy, kiweely drives a real browser window through your tenant connection so you can watch every step live and stop it at any moment.
  • Explicit approval before every mutation: Whether a change goes through an API call or a Workday task screen, kiweely never silently alters your tenant. It presents the exact change it plans to make, waits for your yes, and reads the saved configuration back to verify the result—with one-change-at-a-time guardrails whenever a Production tenant is connected.

Download kiweely for Mac or Windows at kiweely.com/download to see how it handles both API and task-screen work in your own tenant.