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

33 lines
1.4 KiB
Markdown

# 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](http://localhost:8080/swagger-ui).
## Authorization
You'll need to authorize your API requests using a bearer token. To get a token:
```bash
$ 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 `:
```bash
$ 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.