Skip to main content
The SDK throws typed errors for API failures, validation issues, and network problems. The taxonomy mirrors the API’s ErrorResponse envelope, with subclasses per HTTP class for ergonomic catching.

Error class hierarchy

All classes are importable from the package root:

DevhelmApiError

The most common error class — thrown for any non-2xx HTTP response.

DevhelmValidationError

Thrown before HTTP I/O when a request body fails the Zod schema, and after a successful response when the response body doesn’t match the expected schema (rare — usually indicates a stale SDK).

DevhelmTransportError

Thrown for network-level failures (connection refused, DNS, TLS handshake, timeout). The original fetch error is on .cause.

Handling patterns

Catch by HTTP class

Retry on rate limits and 5xx

Don’t retry on DevhelmValidationError, DevhelmAuthError, DevhelmNotFoundError, or DevhelmConflictError — these are deterministic and won’t change without code or config changes.

Deploy lock contention

Catch-all logging

Next steps

Pagination

Iterate through paginated results.

Error patterns

Common error scenarios across all surfaces.