Also take into account other tooling.
For me context was checking if entity A has entity B available - well 404 is totally valid way to return stuff not found. But in my monitoring tooling 404 was spamming my logs - I changed it to 200 { no-this-entity-does-not-have-B } because in the context of my system it is valid response and not an error.
Successful responses (200 – 299) Client error responses (400 – 499)
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
I am not monitoring it per se - but all the tooling we use counts it as an error.
My endpoint is not lying - request is a question "Is there an entity B linked to entity A" - hence answer is always there and it is either "true" or "false", I am not requesting "give me entity B with Id xyz", that is a different endpoint that can return 404 nor prob.
Any time I see status code sidestepping, it informs me that something more basic has been skipped earlier. "The monitoring is firing too often because of 404 errors, we should make this endpoint send back a 200 all the time so we stop being bothered by errors that are not errors" reads to me like curing a symptom.
First app can display a link to document in second app if document is there. What we do is checking via API if document exists - show the link to open it.
Only if user would try to open the link 404 would be correct. Checking if app should show the link 200 with true/false makes much more sense.