Skip to content
Gitdown Developer Docs

Getting started

Start with the operation, then choose the credential class that the target explicitly accepts. Gitdown never treats one credential class as another after verification fails.

Caller REST credential Git credential
Human Firebase ID token as bearer User PAT over HTTPS or enrolled SSH key
Marketplace app Installation-bound app bearer with delegated scopes Not a Git transport identity
Bot Grant-bound bot bearer only on deliberately enabled operations Bot token over HTTPS or separate grant-bound SSH key
Internal service Google service-account OIDC on internal-only routes Not an external Git identity

First public request

Section titled “First public request”

Health is public and needs no credential:

Terminal window
curl --fail-with-body https://dev.gitdown.io/api/healthz

Authenticated REST calls use a bearer header. Keep the value out of URLs and source:

Terminal window
curl --fail-with-body \
  --header 'Authorization: Bearer <REDACTED_FIREBASE_ID_TOKEN>' \
  https://dev.gitdown.io/api/me

The generated reference declares one or more accepted security schemes per operation. Presence of botBearer as a component does not grant blanket bot access; an operation must explicitly map a closed bot permission.

For Git, continue with HTTPS or SSH. For automation identity lifecycle, continue with bot credentials.