Workday errors in plain English.

Submit an Error

RaaS Over OAuth Returns 500 Not Authorized While Basic Auth Works

✓ Verified RaaS (Reports as a Service) 2 lookups
The error 500: Processing error occurred. The task submitted is not authorized.

What does "500: Processing error occurred. The task submitted is not authorized." mean in Workday RaaS?

The same RaaS report works when you call it with the ISU's username and password, but fails the moment you swap to an OAuth access token. The token itself is valid, so this is not a login problem. An OAuth access token only carries the functional areas configured on the API client, and if the area that covers report execution is not in that scope, Workday refuses the call no matter what the underlying ISU is allowed to do.

Quick fix

Add the tenant non-configurable functional area to the API client's scope, request a fresh access token, and retry. An existing token keeps its original scope and will keep failing.

Permanent fix

When registering an API client for reporting, set its scope from what the call needs rather than from the report's subject area alone, and always re-request a token after any scope edit before concluding the change did not work. Keep the API client's Workday account and the report's ownership documented together, since a scope that is correct on paper still fails if the client is registered against an account that cannot see the report.

Troubleshooting

  1. Confirm the token is genuinely valid by checking that the token endpoint returned an access_token and that you are sending it as a bearer token on the report call. A malformed header usually gives 401, not this message, so a 500 here points at scope rather than authentication.
  2. Re-run the identical report URL with basic authentication using the ISU credentials. If that succeeds, the ISU's domain security is already correct and the problem is entirely on the API client.
  3. Run View API Client for the client you registered and look at its Scope, which Workday labels as functional areas. Compare that list against what the report actually touches.
  4. Add the functional area that covers non-configurable tenant behaviour, since RaaS execution falls under it and it is easy to leave out when you only think about the report's subject matter such as Staffing or Compensation.
  5. Request a brand new access token after changing scope. Tokens already issued keep the old scope and will keep failing, which makes a correct fix look like it did nothing.
  6. Retry the report call with the new token.
  7. If it still fails, check which Workday account the API client is registered against. That account, not just the report owner, has to be able to reach the report.
Was this helpful?

Related errors