Design consistent API error responses developers can act on

Help me design consistent, actionable error responses for my API. Current errors: [PASTE EXAMPLE ERROR RESPONSES, CODES, OR THE CODE THAT THROWS THEM] API style: [REST / GraphQL / gRPC - and any existing error format] Who calls the API: [INTERNAL FRONTEND / PARTNER INTEGRATIONS / PUBLIC DEVELOPERS] Constraints: [e.g. "must not reveal whether an email is registered", "existing clients parse the 'message' field", "localized UI messages"] Steps: 1. Audit each current error: is the status code right, can a program branch on it, does a human know what to fix, and is anything leaked? 2. Flag security problems: stack traces, internal hostnames, SQL, library versions, or responses that allow account or resource enumeration (e.g. different errors for "wrong password" vs. "no such user"). 3. Propose one error format (e.g. RFC 9457 Problem Details for HTTP APIs, or my existing convention) with: a stable machine-readable error code, a short human message, field-level details for validation errors, a request or correlation ID, and a docs link placeholder [DOCS LINK]. 4. Rewrite each error. The message must name the problem, the offending field or parameter, and the expected format or valid values. 5. Separate what goes in the response from what goes only in logs (full detail and correlation ID, never secrets or personal data). 6. Note retry guidance: which errors are safe to retry, and when to send Retry-After. Return: - An audit table (original, problem, new code, HTTP status, rewritten message, retryable?). - The error format spec with one validation and one server-error example. - A backward-compatibility note if existing clients may break, with a migration approach. - 5 rules for my team's API style guide.