Skip to content

Feed signing keys ​

ReleaseDesk signs generic update feeds with an app's Ed25519 signing key. Each app can have multiple key records so an older public key remains available after rotation. The private key never appears in an API response. These routes require a GitHub dashboard session; API tokens cannot manage signing keys.

All paths begin with /api/v1/orgs/:orgId/apps/:appId/signing-keys:

Method and suffixMinimum roleSuccess
GET /Viewer200 list
POST /Admin201 new public key record
POST /:id/revokeAdmin200 revoked key record

GET / returns { "items": [...] }, newest first. Each item has id, appId, keyId, publicKey, algorithm (ed25519), createdAt, and revokedAt. keyId is the identifier attached to signatures; id is the record ID used in the revoke path. Keep the two values distinct.

Generate and rotate ​

Send POST / with an empty body to generate a key pair. The response contains the public key record and omits the encrypted private key. The server encrypts the private key at rest with the configured master key. The most recently created non-revoked key signs new generic feed manifests.

To rotate, create a new key, distribute its public key to clients that verify signatures, then revoke the old key when your clients can recognize the new keyId. Creating a new key does not automatically revoke older keys. A revoked key remains in the list so past signatures can still be matched to their key IDs. Revoking an already revoked key returns the existing record.

An unknown app returns 404 app_not_found; a key ID that does not belong to the app returns 404. See API conventions for the error response format.