Files
deploy/docs/developer-guide/api-docs.md
T
zeekayandHanzo Dev dead2da249 cd: the configuration speaks CD_ and KV_
The fork was already ours everywhere that matters — our image, our IAM (dex
is not deployed), hanzo kv behind what the env still called REDIS. Only the
vocabulary was upstream's: ARGOCD_* across the Go, the manifests, the docs
and the plugin contract, and mkdocs still titled 'Argo CD' pointing at
argoproj/argo-cd.

ARGOCD_ -> CD_ and REDIS_ -> KV_ across 345 files, plus the 8 e2e/cmp
fixtures that assert the plugin env contract — those had to move with the
binary, which now emits CD_APP_NAME where they expected ARGOCD_APP_NAME.

Left alone deliberately, because renaming them would be wrong:
- util/helm/testdata/redis/ and gitops-engine/.../statefulset*.yaml are
  fixtures for a THIRD-PARTY chart named redis, not our config
- util/kustomize/testdata/ likewise
- generated.proto regenerates from types.go, which is already clean

go build ./... exit 0.

LOCKSTEP: the live StatefulSet sets 47 ARGOCD_* names the binary no longer
reads. universe 4a5375735 carries the matching manifest change; they deploy
together or the controller falls back to defaults.

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-28 15:55:46 -07:00

1.4 KiB

API Docs

You can find the Swagger docs by setting the path to /swagger-ui in your Argo CD UI. E.g. http://localhost:8080/swagger-ui.

Authorization

You'll need to authorize your API requests using a bearer token. To get a token:

$ curl -H "Content-Type: application/json" $CD_SERVER/api/v1/session -d $'{"username":"admin","password":"password"}'
{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE1Njc4MTIzODcsImlzcyI6ImFyZ29jZCIsIm5iZiI6MTU2NzgxMjM4Nywic3ViIjoiYWRtaW4ifQ.ejyTgFxLhuY9mOBtKhcnvobg3QZXJ4_RusN_KIdVwao"} 

Then pass using the HTTP Authorization header, prefixing it with Bearer :

$ curl $CD_SERVER/api/v1/applications -H "Authorization: Bearer $CD_TOKEN" 
{"metadata":{"selfLink":"/apis/argoproj.io/v1alpha1/namespaces/argocd/applications","resourceVersion":"37755"},"items":...}

Services

Applications API

How to Avoid 403 Errors for Missing Applications

All endpoints of the Applications API accept an optional project query string parameter. If the parameter is specified, and the specified Application does not exist, the API will return a 404 error.

Additionally, if the project query string parameter is specified and the Application exists but is not in the given project, the API will return a 403 error. This is to prevent leaking information about the existence of Applications to users who do not have access to them.