Manage Redpanda using the Admin API

The Redpanda Admin API allows you to manage your cluster and perform operations specific to Redpanda Self-Managed that are not available through the standard Kafka API. You can call the Admin API using any HTTP client.

Most Admin API operations are also available using rpk, a CLI tool that interacts with the Admin API under the hood.

Redpanda v25.3 introduces new endpoints to the Admin API that are served with ConnectRPC. New Redpanda features and operations available starting in v25.3 are accessible as RPC services through these new endpoints. Existing Admin API operations from versions earlier than 25.3 remain available at their current URLs and you can continue to use them as usual (including with rpk v25.3 and later).

Prerequisites

  • A running Redpanda Self-Managed cluster.

  • Superuser privileges, if authentication is enabled on your cluster for the Admin API. For more information, see Configure Authentication. (Some endpoints are read-only and do not require superuser access.)

  • A tool to make HTTP requests, such as curl, or client libraries for your programming language of choice.

    • For Admin API operations introduced in v25.3 and later, you can also make requests using a ConnectRPC client. You can install the Connect plugin for your preferred language and use the Protobuf compiler to generate an SDK. These RPC services are also available in a Buf module, which you can access through the Buf Schema Registry. The Buf CLI provides an easy way to generate client SDKs.

Use the Admin API

Starting in Redpanda v25.3, in addition to RESTful HTTP endpoints, the Admin API serves new endpoints as ConnectRPC services. You can use either autogenerated Protobuf clients or HTTP requests to call ConnectRPC services.

Both new and legacy (RESTful) endpoints are accessible on the same port (default: 9644), but they use different URL paths.

Legacy Admin API endpoints remain available and fully supported. Use them for operations not yet available as ConnectRPC services.

Authentication

If authentication is enabled on your cluster, you must provide credentials with each request, either using HTTP Basic authentication or by including an Authorization header with a bearer token. For example:

curl -u <user>:<password> -X GET "http://localhost:9644/v1/cluster_config"

Use legacy (RESTful) endpoints

The base URL for all requests to the legacy endpoints is:

http://<broker-address>:<admin-api-port>/v1/

For a full list of available endpoints, see the Admin API Reference. Select "v1" in the version selector to view legacy endpoints.

Example request

To use the Admin API to decommission a broker:

  • curl

  • rpk

Send a PUT request to the /v1/brokers/{broker_id}/decommission endpoint:

curl \
 -u <user>:<password> \
 --request PUT 'http://<broker-address>:<port>/v1/brokers/<broker-id>/decommission'

For Linux deployments only, run rpk redpanda admin brokers decommission:

rpk redpanda admin brokers decommission <broker-id>

Use ConnectRPC endpoints

The new endpoints differ from the legacy endpoints in the following ways:

  • You can use a generated ConnectRPC client to call methods directly from your application code, or send curl requests with a JSON payload, as with legacy endpoints.

  • URL paths use the fully-qualified names of the ConnectRPC services.

  • ConnectRPC endpoints accept only POST requests.

Use ConnectRPC endpoints with features introduced in v25.3 such as:

  • Shadowing

  • Connected client monitoring

For a full list of available endpoints, see the Admin API Reference. Select "v2" in the version selector to view the ConnectRPC endpoints.

Example request

To fail over a specific shadow topic from an existing shadow link:

  • curl

  • rpk

Send a POST request to the redpanda.core.admin.v2.ShadowLinkService/FailOver endpoint:

curl \
 -u <user>:<password> \
 --request POST 'http://<broker-address>:<admin-api-port>/redpanda.core.admin.v2.ShadowLinkService/FailOver' \
 --header "Content-Type: application/json" \
 --data '{
  "name": "<shadow-link-name>",
  "shadowTopicName": "<shadow-topic-name>"
}'

  • Request headers Connect-Protocol-Version and Connect-Timeout-Ms are optional.

  • v2 endpoints also accept binary-encoded Protobuf request bodies. Use the Content-Type: application/proto header.

Run rpk shadow failover:

rpk shadow failover <shadow-link-name> --topic <shadow-topic-name>