Overview
Unkey tracks everything for you
Consumption based billing for APIs is getting more and more popular, but it’s tedious to build in house. For low frequency events, it’s quite possible to emit usage events directly to Stripe or similar, but this becomes very noisy quickly. Furthermore if you want to build end-user facing or internal analytics, you need to be able to query the events from Stripe, which often does not provide the granularity required.
Most teams end up without end-user facing analytics, or build their own system to store and query usage metrics.
Since Unkey already stores and aggregates verification events by time, outcome and identity, we can offer this data via an API.
Available data
Unkey stores an event for every single verification, the relevent fields are described below:
Data | Type | Explanation |
---|---|---|
request_id | String | Each request has a unique id, making it possible to retrieve later. |
time | Int64 | A unix milli timestamp. |
key_space_id | String | Each workspace may have multiple key spaces. Each API you create has its own keyspace. |
key_id | String | The individual key being verified. |
outcome | String | The outcome of the verification. VALID , RATE_LIMITED etc. |
identity_id | String | The identity connected to this key. |
tags | Array(String) | Arbitrary tags you may add during the verification to filter later. |
We can return this data aggregated by hour
, day
, month
, tag
, tags
, identity
, key
and outcome
.
As well as filter by identity_id
, key_space_id
, key_id
, tags
, outcome
, start
and end
time.
Example
For an internal dashboard you want to find the top 5 users of a specific endpoint. In order to let Unkey know about the endpoint, you specify it as a tag when verifying keys:
You can now query api.unkey.dev/v1/analytics.getVerifications
via query parameters.
While we can’t provide raw SQL access, we wanted to stay as close to SQL semantics as possible, so you didn’t need to learn a new concept and to keep the translation layer simple.
Name | Value | Explanation |
---|---|---|
start | 1733749385000 | A unix milli timestamp to limit the query to a specific time frame. |
end | 1736431397000 | A unix milli timestamp to limit the query to a specific time frame. |
apiId | api_262b3iR7gkmP7aUyZ24uihcijsCe | The API ID to filter keys. |
groupBy | identity | We’re not interested in individual keys, but the user/org. |
orderBy | total | We want to see the most active users, by how many verifications they’re doing. |
order | desc | We’re ordering from most active to least active user. |
limit | 5 | Only return the top 5. |
Below is a curl command putting everythign together:
You’ll receive a json response with a breakdown of each outcome, per identity ordered by total
.
Was this page helpful?