Skip to main content

View API

View endpoints provide operations for creating, reading, updating, and deleting Iceberg views through the REST Catalog API.

List Views

List all views in a namespace.

Path Parameters

string
required
Optional prefix for multi-tenant deployments
string
required
Namespace identifier (multi-part namespaces use %1F separator)

Query Parameters

string
Pagination token from a previous response
integer
Maximum number of views to return

Response

array
required
List of view identifiers
string
Token for next page of results

Example


Create View

Create a new view in the specified namespace.

Path Parameters

string
required
Optional prefix for multi-tenant deployments
string
required
Namespace identifier

Request Body

string
required
View name
string
View location. If not provided, a location will be generated.
object
required
View schema definition
object
required
Initial view version with query definition
object
View properties

Response

string
required
Location of view metadata file
object
required
Complete view metadata
object
Additional configuration for the view

Example


Load View

Load view metadata from the catalog.

Path Parameters

string
required
Optional prefix for multi-tenant deployments
string
required
Namespace identifier
string
required
View name

Query Parameters

string
Comma-separated list of view identifiers referencing this view

Response

string
required
Location of view metadata file
object
required
Complete view metadata including schema, versions, and properties
object
Additional configuration and credentials for accessing the view

Example


Replace View

Update an existing view with a new version.

Path Parameters

string
required
Optional prefix for multi-tenant deployments
string
required
Namespace identifier
string
required
View name

Headers

string (uuid)
UUIDv7 for idempotent request handling

Request Body

array
Assertions that must be true before applying updates
array
required
Changes to apply to view metadata

Response

string
required
Location of new metadata file
object
required
Updated view metadata

Example

View updates use requirements and updates similar to table commits. Requirements ensure the view hasn’t changed since it was last read.

Check View Exists

Check if a view exists without loading its metadata.

Path Parameters

string
required
Optional prefix for multi-tenant deployments
string
required
Namespace identifier
string
required
View name

Response

No response body. Status code indicates existence.

Example

Success:
Not Found:

Drop View

Delete a view from the catalog.

Path Parameters

string
required
Optional prefix for multi-tenant deployments
string
required
Namespace identifier
string
required
View name

Headers

string (uuid)
UUIDv7 for idempotent request handling

Response

No response body on success.

Example

Success:

Rename View

Rename a view or move it to a different namespace.

Path Parameters

string
required
Optional prefix for multi-tenant deployments

Headers

string (uuid)
UUIDv7 for idempotent request handling

Request Body

object
required
Current view identifier
object
required
New view identifier

Response

No response body on success.

Example

Moving views across namespaces is valid but not all servers support it. Check the 406 response if cross-namespace moves fail.

Register View

Register an existing view using its metadata file location.

Path Parameters

string
required
Optional prefix for multi-tenant deployments
string
required
Namespace identifier

Headers

string (uuid)
UUIDv7 for idempotent request handling

Request Body

string
required
View name to register
string
required
Location of existing view metadata file

Response

Same as Load View response.

Example


Status Codes

Success

  • 200 OK - Request successful with response body
  • 204 No Content - Request successful without response body

Client Errors

  • 400 Bad Request - Invalid request format
  • 401 Unauthorized - Authentication required
  • 403 Forbidden - Not authorized
  • 404 Not Found - View or namespace does not exist
  • 406 Not Acceptable - Operation not supported
  • 409 Conflict - View already exists or commit requirements failed
  • 419 Authentication Timeout - Authentication expired

Server Errors

  • 500 Internal Server Error - Commit state unknown
  • 502 Bad Gateway - Gateway error, commit state unknown
  • 503 Service Unavailable - Service temporarily unavailable
  • 504 Gateway Timeout - Timeout, commit state unknown

View Versions

Views support versioning to track changes over time:
  • Each update creates a new view version
  • Versions contain SQL representations and metadata
  • The current version determines the view’s behavior
  • Version history is maintained in metadata

View Version Structure

Common Patterns

Create View with Multiple Representations

Update View Query

View References

When loading a view that references other views or tables:
This helps track view dependency chains for access control and lineage.

Best Practices

  1. Version management: Keep view version history manageable
  2. Multiple dialects: Provide SQL representations for different engines
  3. Schema evolution: Update schema when view output changes
  4. Dependencies: Track view dependencies using referenced-by
  5. Idempotency: Use idempotency keys for safe retries