Skip to content

List API keys for the authenticated account.

GET
/account/api_key/
curl --request GET \
--url https://api.siteqwality.com/account/api_key/ \
--header 'Authorization: Bearer <token>'

Secrets are never returned: only the stored prefix/suffix fragments, the key type, any scopes, and the lifecycle timestamps. Revoked keys are omitted; expired ones are included so the customer can see why a key stopped working rather than watching it silently disappear.

The response stays a bare array, unchanged in shape from before hashing, so a dashboard build that predates this deploy still renders the list.

API keys, without secrets

Media type application/json
Array<object>

One API key in list responses. Never contains the secret: after creation the secret exists only in the customer’s hands.

object
id
required
string format: uuid
account_id
required
string format: uuid
friendly_name
string | null
key_prefix
required

First 8 characters of the secret, kept in plaintext for display.

string
key_last_four
required

Last 4 characters of the secret, kept in plaintext for display.

string
key_type
required

What a customer API key is allowed to do.

Mirrors the Datadog split between an API key (telemetry push) and an application key (full API access), collapsed into one credential with a type so the ingest path and the management path can share a table.

string
Allowed values: ingest full
scopes
required

Empty means unrestricted.

Array<string>
status
required

Lifecycle state of a key, derived rather than stored so it can never disagree with the timestamps.

string
Allowed values: active expired revoked
created_at
required
string format: date-time
last_used_at
string | null format: date-time
expires_at
string | null format: date-time
revoked_at
string | null format: date-time
Example
[
{
"key_type": "ingest",
"status": "active"
}
]

Missing or invalid authentication

Internal server error