---
title: "Atomically commit a batch of mixed table operations"
method: POST
path: "/v1/table/batch-commit"
tags: ["Table", "Metadata", "Transaction"]
---

# Atomically commit a batch of mixed table operations

`POST /v1/table/batch-commit`

Atomically commit a batch of table operations. This is a generalized version
of `BatchCreateTableVersions` that supports mixed operation types within a
single atomic transaction at the metadata layer.

Supported operation types:
- `DeclareTable`: Declare (reserve) a new table
- `CreateTableVersion`: Create a new version entry for a table
- `DeleteTableVersions`: Delete version ranges from a table
- `DeregisterTable`: Deregister (soft-delete) a table

All operations are committed atomically: either all succeed or none are applied.

## Request body

- BatchCommitTablesRequest — Request to atomically commit a batch of table operations. This replaces `BatchCreateTableVersionsRequest` with a more general interface that supports mixed operations (DeclareTable, CreateTableVersion, DeleteTableVersions, DeregisterTable) within a single atomic transaction at the metadata layer. All operations are committed atomically: either all succeed or none are applied.
  - `identity` Identity — Identity information of a request.
    - `api_key` string — API key for authentication. REST NAMESPACE ONLY This is passed via the `x-api-key` header.
    - `auth_token` string — Bearer token for authentication. REST NAMESPACE ONLY This is passed via the `Authorization` header with the Bearer scheme (e.g., `Bearer <token>`).
  - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
  - `operations` CommitTableOperation[], required — List of operations to commit atomically. Supported operation types: DeclareTable, CreateTableVersion, DeleteTableVersions, DeregisterTable.
    - `declare_table` DeclareTableRequest — Request for declaring a table.
      - `identity` Identity — Identity information of a request.
        - `api_key` string — API key for authentication. REST NAMESPACE ONLY This is passed via the `x-api-key` header.
        - `auth_token` string — Bearer token for authentication. REST NAMESPACE ONLY This is passed via the `Authorization` header with the Bearer scheme (e.g., `Bearer <token>`).
      - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
      - `id` string[]
      - `location` string — Optional storage location for the table. If not provided, the namespace implementation should determine the table location.
      - `vend_credentials` boolean — Whether to include vended credentials in the response `storage_options`. When true, the implementation should provide vended credentials for accessing storage. When not set, the implementation can decide whether to return vended credentials.
      - `properties` object — Business logic properties stored and managed by the namespace implementation outside Lance context, if supported by the implementation.
    - `create_table_version` CreateTableVersionRequest — Request to create a new table version entry. This supports `put_if_not_exists` semantics, where the operation fails if the version already exists.
      - `identity` Identity — Identity information of a request.
        - `api_key` string — API key for authentication. REST NAMESPACE ONLY This is passed via the `x-api-key` header.
        - `auth_token` string — Bearer token for authentication. REST NAMESPACE ONLY This is passed via the `Authorization` header with the Bearer scheme (e.g., `Bearer <token>`).
      - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
      - `id` string[] — The table identifier
      - `version` integer, required — Version number to create
      - `branch` string — Branch to target. When not specified, the main branch is used.
      - `manifest_path` string, required — Path to the manifest file for this version
      - `manifest_size` integer — Size of the manifest file in bytes
      - `e_tag` string — Optional ETag for the manifest file
      - `metadata` object — Optional metadata for the version
      - `naming_scheme` string — The naming scheme used for manifest files in the `_versions/` directory. Known values: - `V1`: `_versions/{version}.manifest` - Simple version-based naming - `V2`: `_versions/{inverted_version}.manifest` - Zero-padded, reversed version number (uses `u64::MAX - version`) for O(1) lookup of latest version on object stores V2 is preferred for new tables as it enables efficient latest-version discovery without needing to list all versions.
    - `delete_table_versions` BatchDeleteTableVersionsRequest — Request to delete table version records. Supports deleting ranges of versions for efficient bulk cleanup.
      - `identity` Identity — Identity information of a request.
        - `api_key` string — API key for authentication. REST NAMESPACE ONLY This is passed via the `x-api-key` header.
        - `auth_token` string — Bearer token for authentication. REST NAMESPACE ONLY This is passed via the `Authorization` header with the Bearer scheme (e.g., `Bearer <token>`).
      - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
      - `id` string[] — The table identifier
      - `branch` string — Branch to target. When not specified, the main branch is used.
      - `ranges` VersionRange[], required — List of version ranges to delete. Each range specifies start (inclusive) and end (exclusive) versions.
        - `start_version` integer, required — Start version of the range (inclusive). Use 0 to start from the first version.
        - `end_version` integer, required — End version of the range (exclusive). Use -1 to indicate all versions up to and including the latest.
    - `deregister_table` DeregisterTableRequest — The table content remains available in the storage.
      - `identity` Identity — Identity information of a request.
        - `api_key` string — API key for authentication. REST NAMESPACE ONLY This is passed via the `x-api-key` header.
        - `auth_token` string — Bearer token for authentication. REST NAMESPACE ONLY This is passed via the `Authorization` header with the Bearer scheme (e.g., `Bearer <token>`).
      - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
      - `id` string[]

## Response `200`

Result of atomically committing a batch of mixed table operations

- BatchCommitTablesResponse — Response for a batch commit of table operations. Contains the results of each operation in the same order as the request.
  - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
  - `transaction_id` string — Optional transaction identifier for the batch commit
  - `results` CommitTableResult[], required — Results for each operation, in the same order as the request operations. Each result contains the outcome of the corresponding operation.
    - `declare_table` DeclareTableResponse — Response for declaring a table.
      - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
      - `transaction_id` string — Optional transaction identifier
      - `location` string
      - `storage_options` object — Configuration options to be used to access storage. The available options depend on the type of storage in use. These will be passed directly to Lance to initialize storage access.
      - `properties` object, nullable — If the implementation does not support table properties, it should return null for this field. Otherwise it should return the properties.
      - `managed_versioning` boolean — When true, the caller should use namespace table version operations (CreateTableVersion, BatchCreateTableVersions, DescribeTableVersion, ListTableVersions, BatchDeleteTableVersions) to manage table versions instead of relying on Lance's native version management.
    - `create_table_version` CreateTableVersionResponse — Response for creating a table version
      - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
      - `transaction_id` string — Optional transaction identifier
      - `version` TableVersion
        - `version` integer, required — Version number
        - `manifest_path` string, required — Path to the manifest file for this version.
        - `manifest_size` integer — Size of the manifest file in bytes
        - `e_tag` string — Optional ETag for optimistic concurrency control. Useful for S3 and similar object stores.
        - `timestamp_millis` integer — Timestamp when the version was created, in milliseconds since epoch (Unix time)
        - `metadata` object — Optional key-value pairs of metadata
    - `delete_table_versions` BatchDeleteTableVersionsResponse — Response for deleting table version records
      - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
      - `deleted_count` integer — Number of version records deleted
      - `transaction_id` string — Optional transaction identifier
    - `deregister_table` DeregisterTableResponse
      - `context` Context — Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation. On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller. REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the `header.` prefix: - On a request, any entry whose key starts with `header.` is sent as an HTTP request header with the prefix stripped. For example, the entry `{"header.Authorization": "Bearer abc"}` is sent as the request header `Authorization: Bearer abc`. - On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with `header.`. For example, the response header `x-request-id: abc123` is returned as the entry `{"header.x-request-id": "abc123"}`.
      - `transaction_id` string — Optional transaction identifier
      - `id` string[]
      - `location` string
      - `properties` object, nullable — If the implementation does not support table properties, it should return null for this field. Otherwise it should return the properties.

## Other responses

- `400` — Indicates 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.
- `401` — Unauthorized. The request lacks valid authentication credentials for the operation.
- `403` — Forbidden. Authenticated user does not have the necessary permissions.
- `404` — A server-side problem that means can not find the specified resource.
- `409` — The request conflicts with the current state of the target resource.
- `503` — The service is not ready to handle the request. The client should wait and retry. The service may additionally send a Retry-After header to indicate when to retry.
- `5XX` — A server-side problem that might not be addressable from the client side. Used for server 5xx errors without more specific documentation in individual routes.

---

[API](https://skmtc.net/lancedb/apis/lance-namespace-specification.md) · [All operations](https://skmtc.net/lancedb/apis/lance-namespace-specification/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/lancedb/lance-namespace-specification/versions/d5b7c114f475/schema)