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

Exception hierarchy

All classes are importable from devhelm:

DevhelmApiError

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

DevhelmValidationError

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

DevhelmTransportError

Wraps httpx network failures (connection refused, DNS, TLS handshake, timeout) so callers don’t need to import httpx. The original exception 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

Client reference

Full method reference for all resources.

Error patterns

Common error scenarios across all surfaces.