# kubectl api-resources: List Available Types

> kubectl api-resources lists every resource type the cluster serves, with short names and groups. Reference for --namespaced, --api-group, --verbs, and CI use.

Source: https://latchkey.dev/learn/command-reference/kubectl-api-resources-list  
Updated: 2026-06-30

kubectl api-resources prints the resource types the API server exposes, including their short names, API group, and whether they are namespaced.

When an apply fails with "no matches for kind", api-resources tells you what the cluster actually serves and under which group/version.

## What it does

kubectl api-resources enumerates every served resource, with columns for NAME, SHORTNAMES, APIVERSION, NAMESPACED, and KIND. Filters narrow it: `--namespaced`, `--api-group`, and `--verbs` restrict to types supporting specific verbs.

## Common usage

```Terminal
kubectl api-resources
# only namespaced types in one group
kubectl api-resources --namespaced=true --api-group=apps
# types you can list and watch (e.g. for RBAC design)
kubectl api-resources --verbs=list,watch -o name
# confirm a CRD kind is served
kubectl api-resources | grep -i certificate
```

## Options

| Flag | What it does |
| --- | --- |
| --namespaced=true|false | Filter to namespaced or cluster-scoped types |
| --api-group=<group> | Restrict to one API group |
| --verbs=<list> | Only types supporting these verbs |
| -o name|wide | Name-only or extended output |
| --sort-by=name|kind | Sort the listing |

## In CI

Run api-resources as a fast preflight: if a kind your manifests use is missing, the CRD is not installed and `apply` will fail with "no matches for kind". `--verbs=list,watch -o name` is handy when generating least-privilege RBAC rules from the real served types.

## Common errors in CI

"error: unable to retrieve the complete list of server APIs: <group>/<version>: the server is currently unable to handle the request" means an aggregated API (often metrics or a flaky webhook) is down; the rest still lists. "couldn\'t get available api versions from server" points at a broken kubeconfig or unreachable API server, not at api-resources itself.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl api-resources: List Available Types?

When an apply fails with "no matches for kind", api-resources tells you what the cluster actually serves and under which group/version.

### What it does?

kubectl api-resources enumerates every served resource, with columns for NAME, SHORTNAMES, APIVERSION, NAMESPACED, and KIND. Filters narrow it: --namespaced, --api-group, and --verbs restrict to types supporting specific verbs.

### In CI?

Run api-resources as a fast preflight: if a kind your manifests use is missing, the CRD is not installed and apply will fail with "no matches for kind". --verbs=list,watch -o name is handy when generating least-privilege RBAC rules from the real served types.

### Common errors in CI?

"error: unable to retrieve the complete list of server APIs: <group>/<version>: the server is currently unable to handle the request" means an aggregated API (often metrics or a flaky webhook) is down; the rest still lists.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt