Skill

api-error-handling

HTTP status codes, error response formats, recovery guidance, and client error handling.

npx claudepluginhub sethdford/claude-skills --plugin engineer-api-development

Popularity

Parent stars

Parent forks

Invocation

How this skill is triggered — by the user, by Claude, or both

Slash command

/api-development:api-error-handling

User invocable

Model invocable

Inline context

Default effort

Context Preview

The summary Claude sees in its skill listing — used to decide when to auto-load this skill

Communicating errors clearly so clients can recover.

SKILL.md

45 lines · ~386 tokens

Similar Skills

errors-and-status-codes

Guides HTTP status code selection (2xx-5xx) and API error response design with envelopes, validation errors, per-field messages, RFC 9457, and Stripe/GitHub/Twilio patterns.

2 files

api-design-principles

HTTP Status Codes

Guides correct HTTP status code selection for API design, error handling, and monitoring. Useful when reviewing PRs, designing endpoints, or debugging client/server error classification.

1 file

harness-claude

handling-api-errors

2.2k

Implements standardized API error handling with RFC 7807 responses, typed error classes, middleware, and monitoring. Use for consistent HTTP errors across endpoints.

3 files6 tools

api-error-handler

Stats

Parent stars13

Parent forks2

MaintenanceFair

Last CommitMar 11, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Stats

Actions

Help us improve

Share bugs, ideas, or general feedback.

API Error Handling

Communicating errors clearly so clients can recover.

Context

You are designing error responses. Be specific; help clients recover.

Domain Context

Status Codes: 4xx (client) vs 5xx (server)

Error Format: Consistent structure across all APIs

Specific Codes: 400 (bad request), 401 (auth), 403 (forbidden), 404 (not found), 429 (rate limited)

Retry Guidance: Transient errors are retryable; permanent are not

Request ID: Include for debugging production issues

Instructions

Use Right Status Code: 4xx for client, 5xx for server

Consistent Format: {"error": {"code": "...", "message": "...", "details": {}}}

Specific Codes: "INVALID_EMAIL" not "bad request"

Retry Guidance: Include Retry-After header

Request ID: Include X-Request-ID for tracing

Human & Machine: Message for humans, code for machines

Document: Every error should be documented

Anti-Patterns

Same error format for all errors; hard for clients to handle

500 for client errors; 4xx/5xx distinction matters

No error codes; clients parse message strings (fragile)

No Retry-After header; clients guess when to retry

Changing error format; breaking change, no warning