REST Custom Object Update Fails: "not found" for a Nested Reference Field's WID
What it means
A PATCH or PUT to a custom object's REST endpoint fails with an invalid request / not found response when a nested reference field's id value is not a WID the platform actually recognizes for that reference type, even though the same id string looks correct and works fine elsewhere. The generic not found wording makes it look like the parent object is missing, when the real problem is the specific id inside the referenced sub-object.
Troubleshooting
- Confirm the flagged id, quoted in the error's error field, by running a GET against that specific referenced object's own REST endpoint. If the GET also returns not found, the id itself is wrong or stale.
- If the GET succeeds, confirm the id is a WID and not an alternate identifier, such as a reference ID, code, or descriptor, that happens to look similar. REST reference fields generally expect the WID specifically.
- Check that the field in the request body is nested under the correct sub-object key exactly as the target REST schema defines it, since a misnested id can also surface as this same not found response.
- Retest with a known-good WID for that reference type, copied directly from a GET response, to confirm the request shape and field names are otherwise correct.
Run a GET on the specific referenced object's own endpoint to confirm the WID exists and belongs to the exact reference type the field expects, then resend the PATCH or PUT with a verified WID.
When building integrations that write nested reference fields, source those reference WIDs from a GET response against the target object's own endpoint rather than from another system's ID or a hand-typed value, so a stale or wrong-type ID is caught before it reaches the write call.