Authentication and access

ReleaseDesk has two ways to call the management API. People sign in with GitHub and use a session cookie. CI jobs and scripts use a ReleaseDesk API token in an Authorization header. Public downloads and feeds have different access rules; they do not use a management API token.

GitHub sign-in

The dashboard starts sign-in through /api/auth/ and keeps the resulting session in a cookie. ReleaseDesk supports GitHub.com and a configured GitHub Enterprise Server. The server checks the account against its allowed GitHub users and organizations before granting access. The first person to sign in can bootstrap a new instance. After that, a person must be allowed by configuration or have an invitation. Access to the instance and membership in a particular ReleaseDesk organization are separate checks.

A ReleaseDesk organization may be linked to a GitHub organization. On sign-in, ReleaseDesk can add members from that GitHub organization and assign roles from its configured team mappings. It also refreshes linked membership in the background. Removing someone from a linked GitHub organization can remove their ReleaseDesk organization access.

Browser requests use the session cookie. For state-changing /api/v1/ requests with an Origin header, the origin must be trusted by the server. The browser UI handles this normally; custom browser clients should use the same server origin or configure a trusted origin. A bearer token is handled separately from cookie-based CSRF protection.

API tokens

An organization admin creates tokens at Settings → Tokens or with POST /api/v1/orgs/:orgId/tokens while signed in. A token begins with rd_. Its plaintext value is returned at creation and cannot be retrieved later. Tokens can be restricted to one app, have an expiration date, and be revoked.

Send a token as a bearer credential:

Authorization: Bearer rd_your_token_here

You can inspect the token's scope without knowing its IDs in advance:

curl -H "Authorization: Bearer $RD_TOKEN" \
  "$RD_URL/api/v1/token/whoami"

The response contains orgId, appId (or null for an organization-wide token), and its scopes. A token for one app cannot operate on a different app. A token for one organization cannot cross into another organization.

Tokens work only on routes that explicitly accept them. Most dashboard administration endpoints require a GitHub session, including token creation, member management, app creation, and signing key management. Tester distribution and the current Google Play and App Store Connect publication routes also require a session. Do not assume an admin token turns a session-only endpoint into a token endpoint.

Roles

Roles are ordered. owner includes admin, developer, and viewer permissions; admin includes developer and viewer; developer includes viewer.

Role	Typical capability
viewer	Read apps, releases, channels, and analytics
developer	Create apps, upload releases, and manage promotions
admin	Manage tokens, testers' administration where required, webhooks, email, and signing keys
owner	Change or delete the organization and configure its GitHub organization link

The role on an endpoint is its minimum. A few operations have additional checks: for example, changing an app's public page settings requires admin even though other app edits allow developer. The eventual endpoint reference should list the precise permission for each operation.

When a signed-in user is not a member of the organization in a path, the API returns 404 for that organization rather than revealing that it exists. A member whose role is too low receives 403.

Token scopes

Scope	Used for
read	Token-enabled reads, such as fetching an app
upload	Uploading artifacts and editing release notes
promote	Promoting, demoting, pausing, resuming, rolling back, and revoking releases
admin	Satisfies a token scope check on routes that accept tokens

Scopes do not grant access to session-only routes. For example, an admin token cannot create another token through the current API.

Downloads and tester access

An artifact promoted to a public channel can be downloaded anonymously. A private artifact needs a signed-in organization member or an expiring signed download URL obtained from the release detail API. The signed URL includes exp and sig query parameters. Treat it as a credential until it expires. Revoked releases return 404 from the download route.

Testers have a separate email sign-in flow at /t/login. A tester portal session is scoped to shared builds; it is not a GitHub dashboard session or an API token. A build shared with a tester group remains private to its recipients unless it is also promoted to a public channel.