Cover: original AI-generated concept illustration with a fictional interface, not a working product screenshot.
Imagine a form that sends an amount to an API. The response identifies the field and a validation rule, but the interface displays only "Request failed." Showing the raw response would expose implementation details; hiding everything gives the user nothing to correct.
One option is a shared mapping from stable error codes to user-facing messages. Another is for each screen to interpret the error in its own context. The shared approach can keep wording consistent, while screen-specific handling can explain exactly which action needs attention.
The awkward case is a new code that the client does not recognize. A fallback still needs to be honest and useful, without inventing a cause or displaying sensitive response content.
Where would you draw the boundary between API-owned meaning and client-owned wording? What should the fallback say, and what safe reference would you give someone who needs support without asking them to copy an entire response body?