REST Catalog API
The REST Catalog API provides a standardized HTTP-based interface for managing Iceberg tables, views, and namespaces. It enables catalog implementations to expose Iceberg metadata operations through REST endpoints.Overview
The REST Catalog API specification defines:- Catalog configuration and discovery
- Namespace operations (create, list, update, delete)
- Table operations (create, load, update, delete, rename)
- View operations (create, load, replace, delete, rename)
- Transaction support for multi-table commits
- Authentication and authorization patterns
API Version
Current Version: 0.0.1Base Path:
/v1
Server URLs
The API uses configurable server URLs:Authentication
The REST Catalog API supports:- OAuth2 - Standard OAuth2 flows for token-based authentication
- Bearer Token - Direct bearer token authentication
Authorization header:
API Endpoints
The REST Catalog API is organized into several functional areas:Configuration
GET /v1/config- Get catalog configuration and server capabilities
Namespaces
GET /v1/{prefix}/namespaces- List namespacesPOST /v1/{prefix}/namespaces- Create a namespaceGET /v1/{prefix}/namespaces/{namespace}- Load namespace metadataHEAD /v1/{prefix}/namespaces/{namespace}- Check if namespace existsDELETE /v1/{prefix}/namespaces/{namespace}- Drop a namespacePOST /v1/{prefix}/namespaces/{namespace}/properties- Update namespace properties
Tables
GET /v1/{prefix}/namespaces/{namespace}/tables- List tablesPOST /v1/{prefix}/namespaces/{namespace}/tables- Create a tableGET /v1/{prefix}/namespaces/{namespace}/tables/{table}- Load table metadataPOST /v1/{prefix}/namespaces/{namespace}/tables/{table}- Update tableDELETE /v1/{prefix}/namespaces/{namespace}/tables/{table}- Drop tableHEAD /v1/{prefix}/namespaces/{namespace}/tables/{table}- Check if table existsPOST /v1/{prefix}/tables/rename- Rename a tablePOST /v1/{prefix}/namespaces/{namespace}/register- Register existing table
Views
GET /v1/{prefix}/namespaces/{namespace}/views- List viewsPOST /v1/{prefix}/namespaces/{namespace}/views- Create a viewGET /v1/{prefix}/namespaces/{namespace}/views/{view}- Load view metadataPOST /v1/{prefix}/namespaces/{namespace}/views/{view}- Replace viewDELETE /v1/{prefix}/namespaces/{namespace}/views/{view}- Drop viewHEAD /v1/{prefix}/namespaces/{namespace}/views/{view}- Check if view existsPOST /v1/{prefix}/views/rename- Rename a view
Transactions
POST /v1/{prefix}/transactions/commit- Commit multi-table transaction
Common Patterns
Namespace Identifiers
Namespaces can be multi-level. Parts are separated by a configurable separator (default:0x1F byte, URL-encoded as %1F):
Pagination
List endpoints support optional pagination via:pageTokenquery parameternext-page-tokenin response
Idempotency
Mutation endpoints support idempotency via theIdempotency-Key header:
- Format: UUIDv7 (RFC 9562)
- Servers must return equivalent responses for repeated requests with the same key
- Key lifetime is advertised in catalog configuration
Prefix Parameter
All endpoints include an optional{prefix} path parameter for multi-tenant deployments:
Response Codes
Success Codes
200 OK- Successful request with response body201 Created- Resource created successfully204 No Content- Successful request without response body304 Not Modified- Resource unchanged (when using ETags)
Client Error Codes
400 Bad Request- Invalid request format or parameters401 Unauthorized- Authentication required or failed403 Forbidden- Authenticated but not authorized404 Not Found- Resource does not exist406 Not Acceptable- Operation not supported409 Conflict- Resource already exists or commit conflict419 Authentication Timeout- Authentication expired422 Unprocessable Entity- Request semantically invalid
Server Error Codes
500 Internal Server Error- Server-side error502 Bad Gateway- Gateway/proxy error503 Service Unavailable- Temporary unavailability504 Gateway Timeout- Gateway timeout
Error Response Format
All error responses use a consistent JSON format:Configuration Discovery
Clients should start by callingGET /v1/config to:
- Discover server capabilities
- Receive default and override configuration
- Learn supported endpoints
- Get idempotency key lifetime
Data Access Delegation
The API supports delegated data access through:Vended Credentials
Servers can provide temporary credentials for accessing table data:Remote Signing
Servers can sign data access requests on behalf of clients:Best Practices
- Always call /config first: Get server capabilities before making other requests
- Use idempotency keys: Ensure safe retries for mutation operations
- Handle pagination: Don’t assume all results fit in one response
- Check supported endpoints: Not all servers implement all endpoints
- Use appropriate timeouts: Respect server processing times
- Cache configuration: Avoid repeated /config calls
- Follow redirect responses: Handle 3xx responses appropriately
Specification Details
For detailed endpoint specifications, see:- Configuration - Catalog configuration and discovery
- Namespaces - Namespace management
- Tables - Table operations
- Views - View operations
OpenAPI Specification
The complete OpenAPI 3.1 specification is available in the Iceberg repository:Reference Implementation
The Iceberg project provides reference implementations:- Java REST catalog client
- Python REST catalog client
- Example server implementations
Related Resources
- Catalog Configuration - Catalog configuration properties
- Table Metadata - Table metadata format
- View Metadata - View metadata format
- OAuth2 Integration - Authentication setup