api-error-handling_skill

This skill enforces standardized API error handling with structured responses, logging, and recovery patterns to improve reliability and observability.
  • TypeScript

52

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill secondsky/claude-skills --skill api-error-handling

  • SKILL.md2.8 KB

Overview

This skill implements standardized API error responses with proper status codes, structured payloads, and integrated logging. It provides a reusable ApiError class, a global error handler, and optional resilience patterns like a circuit breaker for production-ready TypeScript/Node APIs. Use it to make errors predictable, traceable, and safe to return to clients.

How this skill works

The skill defines an ApiError class to represent domain and HTTP errors with code, message, status, requestId, timestamp, and optional details. A global Express-style error handler formats responses, attaches request IDs, hides internal stack traces, and logs server-side failures. A simple CircuitBreaker class is included to stop repeated downstream failures and allow recovery after a timeout.

When to use it

  • Building production REST or GraphQL APIs
  • Standardizing error payloads across services
  • Integrating error monitoring (Sentry, Datadog)
  • Implementing resiliency for external service calls
  • Differentiating client (4xx) vs server (5xx) errors

Best practices

  • Always return a consistent error JSON shape with code, message, status, requestId, and optional details.
  • Attach a unique requestId to every request for tracing across logs and services.
  • Log 5xx errors at error/fatal level and 4xx at warn/info as appropriate; never expose stack traces to clients.
  • Use specific ApiError factory methods (badRequest, notFound, unauthorized) to keep handlers concise.
  • Combine circuit breaker and retry patterns but avoid retries for idempotency-unsafe operations.

Example use cases

  • Validate incoming payloads and return BAD_REQUEST with details per-field for client fixes.
  • Wrap downstream API calls with CircuitBreaker to prevent cascading failures during outages.
  • Throw ApiError.notFound for missing resources and ensure 404 responses include a requestId for support.
  • Capture 5xx errors with logger and send enriched events to Sentry including requestId and user context.
  • Return user-friendly messages for authentication/authorization failures while logging full context internally.

FAQ

Generate or propagate a requestId in middleware (e.g., from headers or a UUID) and attach it to req; the error handler then includes it in the response error.requestId.

Should I expose error details to clients?

Only include actionable, non-sensitive details for client errors (4xx). Never expose stack traces or internal diagnostics for 5xx errors; use logging and monitoring instead.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational