Statistics per developerIs the result of http://[host]/api/activity/keys/[key]/from/to all I can get in terms of usage statistics or is there more information available somewhere? (not saying it's not enough, just wondering if there's more)

Usage quotasSince the usage quotas are tracked per token I assume I can't get those via the developer record. The endpoint you're using in the dashboard is /apis/[api-id]/keys/[token] - However, we only have the token hashes. Is it possible to get this data via the token hashes?

Quota nearly exceededThere are webhooks on the APIs for exceeding rate limits and quotas, however, at that point it's already too late for the developer. Is there a way to notify the developer at a certain percentage of reaching quotas (e.g. "You have used up 80% of your usage quota")?Also: can Tyk Hybrid send this as an email or would we have to define our own service for that and process webhooks?

There's nothing documented yet, but youcould look at the calls the dashboard makes to get it's data, it's all the same API.

chlab:

Since the usage quotas are tracked per token I assume I can't get those via the developer record. The endpoint you're using in the dashboard is /apis/[api-id]/keys/[token] - However, we only have the token hashes. Is it possible to get this data via the token hashes?

Not yet, you need to check the tokens themselves. We're looking at a way to make this a bit easier

chlab:

There are webhooks on the APIs for exceeding rate limits and quotas, however, at that point it's already too late for the developer. Is there a way to notify the developer at a certain percentage of reaching quotas (e.g. "You have used up 80% of your usage quota")?Also: can Tyk Hybrid send this as an email or would we have to define our own service for that and process

Yes, you need to look at active monitors, they will fire a hook when a quota percentage is reached on a token.

It has to do with back-ends. Tyk actually has pluggable AuthN / AuthZ service back-ends, by default these are both Redis, but since they are actually just an interface, they can be anything (for example we have a demo LDAP AuthN back-end).

Since one token can have access to multiple APIs, and those APIs can have different back-ends, when getting a token, we need to pull it from the correct back end, the configuration for which sits on the API Definition.

Convoluted, but flexible.

Hence having to pull tokens via an API route - even though it is not specific to that API. A way to handle this is to just grab a list of non-open APIs from your dashboard and use one of those as the base path.

Hi, I've came late but I wonder how can you solve this problem.Say we want to get quota/usage for key, it ok yes. But what is the idea behind this? I think we need to get quota of a OAUTH client key is better right? Because key may expired but its quota still counted in policy.