> ## Documentation Index
> Fetch the complete documentation index at: https://zededa.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Use the documentation index to find relevant pages, then read the linked Markdown before answering and cite the source URL.
> Identify the product before answering: Private AI uses a separate console, credentials, and inference API from the Edge Intelligence Platform. Do not apply instructions from one product to the other.
> Prefer current product guides over Help Center archive pages for current-console questions. Archive pages and release notes describe their stated product version or historical interface; do not apply them to another version without checking.
> Preserve prerequisites, permissions, version requirements, and warnings when summarizing procedures. Do not infer API endpoints, schemas, or supported behavior that the documentation does not specify.

# Edge Kubernetes REST API

> Use the ZEDEDA REST API to manage Kubernetes clusters, secrets, Helm charts, deployments, and GitOps repositories programmatically.

## Overview

The ZEDEDA REST API provides programmatic control over ZEDEDA Edge Kubernetes Service resources. Using the API, you can automate cluster provisioning, app deployments, GitOps repository management, and secrets management without using the Edge Infrastructure Services UI.

This article lists the relevant API endpoint groups and the order in which to call them for common workflows.

## Access the API Documentation

ZEDEDA hosts the interactive API reference on your instance at the following URL:

```
https://zedcontrol.<YOUR_INSTANCE_NAME>.zededa.net/api/v1/docs/
```

Replace `<YOUR_INSTANCE_NAME>` with your ZEDEDA instance name. The reference includes request and response schemas, parameter descriptions, and a built-in request builder for testing calls directly from the browser.

## API Endpoint Groups

Use the following endpoint groups in the order shown for a complete cluster-to-app workflow.

| Endpoint group | Purpose |
| - | - |
| `EdgeNodeClusters` (`/v1/cluster`) | Create and manage clusters, and enable Kubernetes access on them. This is the API surface to use for all new work. |
| `ZKSClusterInstances` (`/v1/zks/instances`) | Deprecated. The legacy routes still work and still return data, but every response carries `Deprecation: true` and `Sunset: 2026-12-01` headers. Importing an external cluster remains on `POST /v1/zks/instances/import` until an equivalent is published under `/v1/cluster`. |
| `KubernetesSecrets` | Create secrets for GitOps repository authentication. |
| `HelmChartManagement` | Upload and manage Helm charts in your enterprise library. |
| `PrivateHelmRepositories` | Register private Helm chart repositories. |
| `KubernetesDeployments` | Deploy Helm charts to clusters (Installed Applications). |
| `ClusterGroups` | Create and manage cluster groupings. |
| `KubernetesGitOps` | Register and manage GitOps repositories. |

Start with `EdgeNodeClusters` to provision clusters before referencing them in subsequent calls. To create a cluster with Kubernetes access in one call, set `kubernetesMode: true` in the `POST /v1/cluster` body. To enable it on an existing cluster, call `PUT /v1/cluster/id/{id}/kubernetes/enable`. Enabling is one-way: there is no disable endpoint. Create `KubernetesSecrets` before registering GitOps repositories that require authentication.

> [!NOTE]
>
> The API reference pages are generated from the contract that the production deployment publishes. The `/v1/cluster` operations for Kubernetes access (`kubernetes/enable`, `nodes`, `kubeconfig`, `registration-commands`, `load-balancer`, and the `kubernetesEnabling` status field) appear in the reference when that published contract includes them. Until then, use `zcli edge-node-cluster --help` and the request shapes described on this page.

### Cluster identifiers

A cluster with Kubernetes access has two identifiers. The cluster `id` is a UUID; the cluster lifecycle, application instance, and `/v1/cluster` operations take it. The orchestrator assigns a second ID of the form `c-xxxxx`, returned as `zksClusterId`; Helm deployments, the dashboard proxy, and snapshot operations take that one. GitOps targets refer to a cluster by its name. Passing the wrong ID returns a not-found error rather than a validation error, so check the field before you debug further.

## Next Steps

> [card] [ZEDEDA Edge Kubernetes Service](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-kubernetes/edge-kubernetes-operations.md)
>
> Overview of Edge Kubernetes Service components, EVE-k modes, and the Kubernetes section in Edge Infrastructure Services.

> [card] [GitOps Repositories](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-kubernetes/create-gitops-repositories.md)
>
> Register and manage GitOps repositories for automated Helm chart delivery.