Skip to main content
Common error codes and their meanings
The 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 Accepted for all async operations (BMC, K8s interactions)
  • Use 207 Multi-Status for all batch operations (indicates partial success possible)
  • Use 409 Conflict for 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 the error.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 use 207 Multi-Status with per-resource error details:
Note: Bulk operations always return success: true at the top level, with per-resource status in the results array.

Error Handling Best Practices

For API Consumers

  • Check the success field - 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 details field - Provides additional context for validation errors
  • Implement retries - For 500 and 429 errors with exponential backoff

Example Client Code

Rate Limiting

Rate limit errors return 429 Too Many Requests with a Retry-After header indicating when to retry.
Check the Retry-After response header for the recommended retry delay in seconds.