Get API usage
Your own API consumption, broken down per key, per endpoint and per day. The same figures the Usage panel in Settings renders.
This is API request usage, which is distinct from product credit consumption — API calls do not consume credits. For the credit balance see Credits.
GET /v1/usageAuthorization
| Header | Type | Required |
|---|---|---|
Authorization | Bearer asky_sk_… | required |
Query parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
days | integer | optional | Days of history, 1 to 400. Defaults to 30. Successful requests are retained for 90 days and failures for 400, so a window past 90 days shows errors more completely than successes. |
Request
cURL
curl --request GET \
--url 'https://api.askylabs.com/v1/usage' \
--header 'Authorization: Bearer <api-key>'Response
200
{
"data": {
"totals": { "requests": 4820, "errors": 31, "client_errors": 28, "server_errors": 3 },
"keys": [
{
"api_key_id": "6e3fbbff-4230-421f-ae3a-3d4d63a83f10",
"requests": 4820,
"errors": 31,
"client_errors": 28,
"server_errors": 3,
"response_bytes": 1048576,
"p95_ms": 212
}
]
},
"meta": {
"period": { "since": "2026-07-14", "days": 30 }
},
"request_id": "req_39ae1c78f0b2456d8e14"
}Response fields
| Field | Type | Description |
|---|---|---|
meta.period | object | required. { since, days } — the resolved window, not the raw days you passed |
data.totals | object | required. { requests, errors, client_errors, server_errors }, summed across every key |
data.keys | object[] | required. One entry per API key that made at least one request in the window |
data.keys[].api_key_id | uuid | required |
data.keys[].requests | integer | required |
data.keys[].errors | integer | required. client_errors + server_errors |
data.keys[].client_errors | integer | required. 4xx responses |
data.keys[].server_errors | integer | required. 5xx responses |
data.keys[].response_bytes | integer | required. Total response size this key has been sent |
data.keys[].p95_ms | number | null | The slowest endpoint’s p95 latency, not an average across endpoints. null when no timed request exists |
request_id | string | required. Also returned as the x-request-id header. Quote it when contacting support |
Errors
| Status | Code | When |
|---|---|---|
| 400 | invalid_request | A parameter is unknown or malformed. The message names it |
| 401 | invalid_token | The key is missing, malformed, or does not exist |
| 401 | token_expired | The key passed its expiry date |
| 401 | token_revoked | The key was revoked |
| 429 | rate_limited | Over 300 requests per minute. See the Retry-After header |
Notes
Figures are live for the last 60 days, batched before that. Recent activity comes straight from the request log; anything older is stitched from a daily rollup instead. Either way a call made seconds ago is already counted, so this is safe to use as confirmation that an integration is working rather than waiting for an hourly rollup.
Rejected requests count too. A 401 from an expired key, a 429, or a 400 from a bad parameter all appear here. A key that has stopped working shows up as errors rather than as silence, which is the point.
Errors are split into client-caused and server-caused right in the response. client_errors is
4xx (your request); server_errors is 5xx (ours). errors is their sum.
Per-endpoint and per-day are not broken out. This reports one row per API key, not per endpoint or per day, on the reasoning that the real question is “which of my integrations is doing what” and our own guidance is one key per integration. Widening this to a finer breakdown later is additive.