REST Custom Object 404 "not found: id" Is Often a JSON Syntax Error, Not a Missing Record
What it means
A PUT or POST to a custom object endpoint, often from Studio's workday-out-rest component, returns a 404 not found: id even though the WID referenced in the payload is correct. The message is misleading: this response commonly shows up when the JSON body itself has a syntax or type mistake, like a malformed date field, not because the referenced record is actually missing.
Troubleshooting
- Confirm the WID or reference ID in the payload is genuinely correct by looking it up directly, for example with a GET on the same object. Don't assume the ID is wrong just because the error says not found.
- Strip the request down to a minimal payload with just one or two fields and resend. If that succeeds, the endpoint and ID are fine and the problem is in the fields you removed.
- Run a GET against the same custom object endpoint for an existing record and compare the exact field names, nesting, and value formats, especially date fields, against what you're sending in the PUT or POST.
- Add fields back into the payload one at a time, or in small groups, until the 404 reappears. That isolates the specific field or syntax issue causing Workday to reject the whole request as not found.
Run a GET on the custom object endpoint for a known record, and match your outbound PUT or POST payload's field names, nesting, and date formatting exactly to what the GET response shows before resending.
Build every custom object integration by first mirroring a GET response for a known record and templating new outbound payloads from that, rather than hand writing JSON from documentation. Add a field-by-field payload validation step to the build process so a single malformed field surfaces as a syntax error during development, not as a confusing not found in production.