social.coves.aggregator.createApiKey
Create an API key for the authenticated aggregator. Requires OAuth authentication. The API key is returned ONCE and cannot be retrieved again. Store it securely.
Details · procedure
| Kind | procedure |
|---|---|
| Authority | aggregator.coves.social |
| Indexed |
Procedure
procedure · POSTInput
application/jsonOutput
application/jsonISO8601 timestamp when the key was created
DID of the aggregator that owns this key
The plain-text API key. This is shown ONCE and cannot be retrieved again. Format: ckapi_<64-hex-chars> (32 bytes hex-encoded)
maxLength: 256
First 12 characters of the key (e.g., 'ckapi_ab12cd') for identification in logs and UI
maxLength: 64
Errors
AuthenticationRequired
OAuth authentication is required to create an API key
OAuthSessionRequired
OAuth session is required (not service JWT) to create an API key
AggregatorRequired
Only registered aggregators can create API keys
KeyGenerationFailed
Failed to generate the API key
Similar lexicons
semantic matchLexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.
-
dev.cocore.account.createApiKey
procedureMint a new cocore API key for the authenticated account. Authenticate with either a console session cookie or an existing `Authorization: Bearer cocore-...` key. The full secret is returned exactly once in `secret` and is never retrievable again — only its SHA-256 hash is stored. Use the returned key to authenticate subsequent automated requests (inference, the record proxy, and these key-management methods themselves).
-
Get information about the authenticated aggregator's API key. Note: The actual key value is NEVER returned - only metadata about the key.
-
social.coves.aggregator.revokeApiKey
procedureRevoke the authenticated aggregator's API key. After revocation, the aggregator must complete OAuth flow again to create a new API key. This action cannot be undone.
-
List every API key belonging to the authenticated account, most-recently-created first. The owning DID is derived from the credential presented (session cookie or `Authorization: Bearer cocore-...`); there is no way to list another account's keys. Secrets are never returned — see `apiKeyView`.