REST Custom Object Update Fails with Nested Reference Not Found
What it means
You are POSTing to a custom object endpoint with updateIfExists=true to set a nested custom-list field, and Workday reports the referenced ID as not found even though the WID looks valid. Two unrelated setup issues can produce this same generic error.
Troubleshooting
- Confirm the field name in your JSON body still matches the object's active field name. Deactivating and recreating a field on a custom object (even one that looks like a rename) can leave the old field name responding to reads but rejecting writes.
- Check whether the nested value is a custom list or picklist entry rather than a real business object reference. Custom list entries are addressed by their own instance/reference ID, not by the WID of the record they represent.
- Re-fetch the target record with a GET first and compare the exact key names and id values Workday returns against what your integration is sending.
Swap the WID in the nested reference for the custom list's own instance/reference ID, and update the field name in the payload to match the object's current active field name.
When building custom object integrations, generate the field names and reference ID types directly from the object's current REST schema (or a GET response) at build time instead of hardcoding them, so a later field rename or deactivation on the object surfaces as a clear schema mismatch rather than a cryptic not-found error.