Common error codes and their meaningsThe k0rdent API uses standard HTTP status codes and structured error responses to communicate failures clearly.
Error Response Structure
All error responses follow a consistent structure with the discriminated union envelope:Error Object Fields
HTTP Status Codes
The k0rdent API uses the following HTTP status codes:Key Patterns
- Use
202 Acceptedfor all async operations (BMC, K8s interactions) - Use
207 Multi-Statusfor all batch operations (indicates partial success possible) - Use
409 Conflictfor invalid state transitions (e.g., provisioning an already-provisioned server) - Always include error codes in response body, not just HTTP status
Common Error Codes
The API uses machine-readable error codes in theerror.code field:
Error Examples
Validation Error
Not Found Error
Invalid State Transition
Capacity Exceeded
Typed Error Classes
The k0rdent API implementation uses typed error classes for consistency:AppError
Base error class for all application errors:ValidationError
Used for request validation failures:NotFoundError
Used when a resource cannot be found:ForbiddenError
Used when the user lacks permission:ConflictError
Used for resource state conflicts:InvalidStateTransitionError
Used for invalid state transitions:Bulk Operation Errors
Bulk operations use207 Multi-Status with per-resource error details:
success: true at the top level, with per-resource status in the results array.
Error Handling Best Practices
For API Consumers
- Check the
successfield - Use TypeScript discriminated unions for type safety - Log
requestId- Always log the request ID for debugging - Handle specific error codes - Don’t rely solely on HTTP status codes
- Parse
detailsfield - Provides additional context for validation errors - Implement retries - For
500and429errors with exponential backoff
Example Client Code
Rate Limiting
Rate limit errors return429 Too Many Requests with a Retry-After header indicating when to retry.
Retry-After response header for the recommended retry delay in seconds.