List all catalog configuration settings

get

{scheme}://{host}/{basePath}/v1/config

All REST clients should first call this route to get catalog configuration properties from the server to configure the catalog and its HTTP client. Configuration from the server consists of two sets of key/value pairs.

defaults - properties that should be used as default configuration; applied before client configuration
overrides - properties that should be used to override client configuration; applied after defaults and client configuration

Catalog configuration is constructed by setting the defaults, then client- provided configuration, and finally overrides. The final property set is then used to configure the catalog.

For example, a default configuration property might set the size of the client pool, which can be replaced with a client-specific setting. An override might be used to set the warehouse location, which is stored on the server rather than in client configuration.

Common catalog configuration settings are documented at https://iceberg.apache.org/docs/latest/configuration/#catalog-properties

The catalog configuration also holds an optional endpoints field that contains information about the endpoints supported by the server. If a server does not send the endpoints field, a default set of endpoints is assumed:

GET /v1/{prefix}/namespaces
POST /v1/{prefix}/namespaces
GET /v1/{prefix}/namespaces/{namespace}
DELETE /v1/{prefix}/namespaces/{namespace}
POST /v1/{prefix}/namespaces/{namespace}/properties
GET /v1/{prefix}/namespaces/{namespace}/tables
POST /v1/{prefix}/namespaces/{namespace}/tables
GET /v1/{prefix}/namespaces/{namespace}/tables/{table}
POST /v1/{prefix}/namespaces/{namespace}/tables/{table}
DELETE /v1/{prefix}/namespaces/{namespace}/tables/{table}
POST /v1/{prefix}/namespaces/{namespace}/register
POST /v1/{prefix}/namespaces/{namespace}/tables/{table}/metrics
POST /v1/{prefix}/tables/rename
POST /v1/{prefix}/transactions/commit

Recent Requests

Time	Status	User Agent
Retrieving recent requests…

Loading…

Responses

200Server specified configuration values.

400Indicates a bad request error. It could be caused by an unexpected request body format or other forms of request validation failure, such as invalid json. Usually serves application/json content, although in some cases simple text/plain content might be returned by the server's middleware.

401Unauthorized. The REST Catalog SHOULD respond with the 401 UnauthorizedResponse when the access token provided is expired, revoked, malformed, or invalid for other reasons. The client MAY request a new access token and retry the request.

403Forbidden. Authenticated user does not have the necessary permissions.

419This is an optional status response type that the REST Catalog can issue when the token has expired. The client MAY request a new access token and retry the request. 401 UnauthorizedResponse SHOULD be preferred over this response type on token expiry.

503The service is not ready to handle the request, request could have been partially processed. The service may additionally send a Retry-After header to indicate when to retry, a non idempotent request should only be retried by the client when the Retry-After header is present.

5XXA server-side problem that might not be addressable from the client side. Used for server 5xx errors without more specific documentation in individual routes.