API Architecture
The Cluster API differs from the Cloud API in several important ways:Cloud API
- Manages CockroachDB Cloud resources
- Hosted at cockroachlabs.cloud
- Uses bearer token authentication
- Controls cluster lifecycle
Cluster API
- Monitors individual clusters
- Hosted on each cluster node
- Uses session-based authentication
- Provides runtime metrics
Base URL
The Cluster API is hosted by all nodes in your cluster on the same port as the DB Console:8080. You can configure it using --http-addr={server}:{port} when starting nodes.
Example URLs
Local Development
Production Cluster
Authentication
Most Cluster API endpoints require authentication using a session token. The/health and /login endpoints do not require authentication.
Requirements
To authenticate with the Cluster API, you need:- A SQL role that is a member of the
adminrole - Login permissions for that role
- A password set for the role
Using cockroach auth-session CLI
The recommended way to manage sessions is using thecockroach auth-session command:
Create a session
Use the session token
Direct Login via API
You can also authenticate directly through the/login endpoint:
POST
Logout
Invalidate your session token:POST
Secure Cluster Requirements
To connect to the API on a secure cluster, you need:- The CA certificate used by the cluster, either:
- Installed in your system’s trusted certificate store, OR
- Provided explicitly in your HTTP client (e.g., curl’s
--cacertoption)
Using curl with CA cert
API Versioning
The Cluster API version is defined in the request path:/api/v2/
- Current version: v2.0
- Future CockroachDB versions may provide multiple API versions
- The v2.0 API will remain available until deprecated
Version Stability
Within v2.x:- All endpoint paths remain available
- Response payloads maintain backward compatibility
- Patch versions (v2.x) may add new endpoints
- Patch versions will not remove existing endpoints
Available Endpoints by Category
Cluster Status
- Health Check:
/health- Verify node health and readiness - Nodes:
/nodes- List all nodes and their details - Node Ranges:
/nodes/{node_id}/ranges- Get ranges on a node
Database Information
- Databases:
/databases- List all databases - Database Details:
/databases/{database}- Get database descriptor - Database Grants:
/databases/{database}/grants- List privileges - Tables:
/databases/{database}/tables- List tables in database - Table Details:
/databases/{database}/tables/{table}- Get table schema
Cluster Monitoring
- Events:
/events- List recent cluster events - Sessions:
/sessions- Get active SQL sessions - Hot Ranges:
/ranges/hot- Find high-traffic ranges - Range Details:
/ranges/{range_id}- Get detailed range info
User Management
- Users:
/users- List SQL users - Login:
/login- Authenticate and get session token - Logout:
/logout- Invalidate session token
Endpoint Stability
Each endpoint has a stability classification:Supported for production use. Will maintain backward compatibility within v2.x.
Subject to change. May be modified or removed in future releases. Use with caution in production.
Common Use Cases
Health Monitoring
Health Monitoring
Continuously check cluster health for monitoring systems:Returns HTTP 200 if the node is healthy and ready for SQL connections.
Node Discovery
Node Discovery
List all nodes in the cluster with their versions and status:Useful for inventory, version tracking, and capacity planning.
Database Inventory
Database Inventory
Enumerate all databases and tables:Essential for backup planning and schema management.
Performance Troubleshooting
Performance Troubleshooting
Identify hot ranges with high read/write activity:Helps diagnose performance issues and plan data distribution.
Next Steps
Cluster Status Endpoints
Monitor nodes, ranges, and cluster status
Health Endpoints
Check node health and readiness
Database Management
Query databases and tables
Full API Reference
Complete Cluster API documentation