---
title: "Drop a namespace"
method: POST
path: "/v1/namespace/{id}/drop"
tags: ["Namespace"]
---

# Drop a namespace

`POST /v1/namespace/{id}/drop`

Drop a namespace. The namespace must be empty.

## Path parameters

- `id` string, required

## Query parameters

- `delimiter` string, nullable — An opaque token that allows pagination for list APIs (e.g. ListNamespaces). For an initial client request for a list API, if the server cannot return all items in one response, or if there are more items than the `pageSize` specified in the client request, the server must return a `nextPageToken` in the response indicating there are more results available. After the initial request, the value of `nextPageToken` from each response must be used by the client as the `pageToken` parameter value for the next request. Clients must interpret either `null`, missing value or empty string value of `nextPageToken` from a server response as the end of the listing results.

## Request body

- DropNamespaceRequest
  - `name` string, required
  - `parent` string[]
  - `mode` 'SKIP' | 'FAIL' — The mode for dropping a namespace, deciding the server behavior when the namespace to drop is not found. - FAIL (default): the server must return 400 indicating the namespace to drop does not exist. - SKIP: the server must return 204 indicating the drop operation has succeeded.
  - `behavior` 'RESTRICT' | 'CASCADE' — The behavior for dropping a namespace. - RESTRICT (default): the namespace should not contain any table or child namespace when drop is initiated. If tables are found, the server should return error and not drop the namespace. - CASCADE: all tables and child namespaces in the namespace are dropped before the namespace is dropped.

## Response `200`

Result of dropping a namespace

- DropNamespaceResponse
  - `name` string
  - `parent` string[]
  - `properties` unknown
  - `transactionId` string — If present, indicating the operation is long running and should be tracked using GetTransaction

## 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.

## Changes

- **2025-07-21** `6790486d1fac` — 10 breaking, 19 warning, 30 info
  - added the new required request property `name`
  - request property `behavior` was restricted to a list of enum values
  - request property `mode` was restricted to a list of enum values
  - removed the required property `code` from the response with the `400` status
  - …55 more

[Change history](https://skmtc.dev/lance-format/apis/lance-namespace-specification/changes/v1/namespace/:id/drop/post.md)

---

[API](https://skmtc.dev/lance-format/apis/lance-namespace-specification.md) · [All operations](https://skmtc.dev/lance-format/apis/lance-namespace-specification/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/lance-format/lance-namespace-specification/revisions/6790486d1fac/schema)