| name | handling-api-errors |
| description | Implement standardized error handling with proper HTTP status codes and error responses.
Use when implementing standardized error handling.
Trigger with phrases like "add error handling", "standardize errors", or "implement error responses".
|
| allowed-tools | Read, Write, Edit, Grep, Glob, Bash(api:error-*) |
| version | 1.24.0 |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| license | MIT |
| tags | ["api","handling-api"] |
| compatibility | Designed for Claude Code, also compatible with Codex and OpenClaw |
Handling API Errors
Overview
Implement standardized API error handling with RFC 7807 Problem Details responses, centralized error middleware, typed error classes, and environment-aware stack trace exposure. Convert framework exceptions, validation failures, database errors, and upstream service failures into consistent, machine-readable error responses with appropriate HTTP status codes.
Prerequisites
- Web framework with middleware/error handler support (Express, FastAPI, Spring Boot, Gin)
- Structured logging library for error event recording with correlation IDs
- Error monitoring service: Sentry, Bugsnag, or Rollbar for production error tracking
- RFC 7807 Problem Details specification for response format guidance
- API documentation listing all possible error codes and their meanings
Instructions
- Audit existing error handling using Grep to find
try/catch blocks, error middleware, and exception handlers, identifying inconsistent error response formats across endpoints.
- Define a standardized error response envelope following RFC 7807:
type (URI identifying error type), title (human-readable summary), status (HTTP code), detail (specific explanation), and instance (request path).
- Create typed error classes for each error category:
ValidationError (400), AuthenticationError (401), AuthorizationError (403), NotFoundError (404), ConflictError (409), and RateLimitError (429).
- Implement centralized error handling middleware that catches all thrown errors, maps them to the appropriate HTTP status code and RFC 7807 body, and prevents raw stack traces from leaking to clients.
- Add validation error formatting that transforms framework-specific validation failures into a consistent array of field-level errors with
field, message, and code properties.
- Configure environment-aware error detail: include stack traces and internal error codes in development/staging responses; omit them in production while logging the full error server-side.
- Integrate error monitoring (Sentry/Bugsnag) that captures 5xx errors with full context (request details, user info, stack trace) and groups them by root cause for triage.
- Handle unhandled rejections and uncaught exceptions at the process level, returning 500 with a generic error message while logging the full failure and triggering alerts.
