How should error codes and messages be presented in public APIs?

• A. Expose internal stack traces
• B. Use consistent error models with machine-readable codes
• C. Return only generic messages
• D. Use random codes

Answer: (B)

Use a consistent, machine-readable error model for public APIs. This means returning structured error information that includes a stable error code, an accompanying human-friendly message, and optional details. The code acts as a contract that developers can rely on across versions and languages, so client applications can implement deterministic handling: map specific codes to UI messages, decide when to retry, or trigger automated alerts and dashboards. Keeping the code stable and well-documented also supports localization and analytics, making it easier to monitor error patterns and improve the API over time.

Exposing internal stack traces is risky because it leaks implementation details and can reveal security weaknesses. Returning only generic messages deprives clients of actionable information and hinders proper handling. Using random codes destroys consistency and makes it impossible for clients to rely on a known taxonomy of errors.