This graph (incorrectly) shows 0 requests for today.
The help box says:
This screen represents the activity for a single API key over time, and will display ‘Combined traffic’, ‘Errors’ and ‘Successful requests’. Errors returned by the Tyk platform are grouped in the table to the left.
API Usage Data / Activity by Key
I select my developer, even though it’s a different key hash (de62cccd) and the chart displays the correct data. If I send another request against my API, the usage count increases accordingly.
Btw: when I use the search, it always shows the same listing regardless of what I search for.
The help box says the exact same thing as the other page.
So my questions are:
what is the difference between the two analytics?
why doesn’t the analytics graph for the developer show any activity?
what hash am I seeing on the “activity by key” page?
Did you generate the token you’re trying to find analytics data for in the portal or somewhere else? It sounds like you might be looking at the wrong key (key hashes are unique to the keys themselves).
I generated the token via API (key request) and am using the hashed token for the request. It correlates to the hashed token I see when I check analytics with the first method mentioned above (via developers).
I don’t know what kind of hash I’m seeing with the second method (activity by key).
I’m not sure i follow how you are generating the keys and what you are doing with the hashes - the hashes aren’t really used for anything except to identify a key.
Can I suggest you run your experiment again, but this time add an alias to the key when you create it - the alias will pass through to the analytics records and will show in the by-key view.
If you created a token using the portal methods and used a genuine portal developer with a username and metadata, then Tyk will already have filled in the alias for you.
I think the problem here is it’s unclear on what you are doing, how you have achieved it and then how that leads to whatever confusion there is with keys.
In Tyk, there is one hash per key, so if you are seeing two, then you must have generated and used two tokens.
Can you list the exact API commands or steps that you used to generate your key? And then provide screenshots of what seems to be the problem?
I’m not sure i follow how you are generating the keys and what you are doing with the hashes - the hashes aren’t really used for anything except to identify a key.
I’m using the hash to get the activity for that key via GET /activity/keys/<hash>/from/to. I am not explicitly passing an alias, but when I look up the key in the Tyk Dashboard, I’m seeing the user email as the alias.
(btw. searching for a username with the “This is a username” flag on the System Management > Keys page doesn’t work for me. I need the unhashed key, which will not be possible in production :/)
I think the problem here is it’s unclear on what you are doing, how you have achieved it and then how that leads to whatever confusion there is with keys.
I am doing the following:
Register developer via POST /portal/developers
Request key for a policy via POST /portal/requests (v2)
Approve key via PUT /portal/requests/approve/<id>
Since that only returns the RawKey, I then get the hashed token via GET /portal/developers/<id>. This returns the developer data along with a subscriptions dictionary, which I use to match the policy I requested the token for (I think you told me to get the key hash this way in another thread on here):
"subscriptions": {
"<policy-id>": "b88634e9"
}
In the test that I just did, I’m getting b88634e9 in step 4. However, the key hash I’m seeing in the Tyk Dashboard > Activity by key, is a613ecc9. The alias displayed with it is the email of the developer I registered in step 1, so it’s definitely the key that I mean.
My question is: how do I get the a613ecc9 hash and what is the b88634e9 I’m seeing in step 3?
I believe you have discovered a bug We’ll bundle it into our next release to fix. For some reason the wrong hash is being attached to a developer record.
(just to update on this - this seems to affect a subset of accounts, we’re trying to isolate the issue but it does not seem to happen consistently - it does not affect newer accounts, for example).
Have you made any specific configuration changes to your setup that are away from the vanilla installation? In particular your dashboard setup?
Have you made any specific configuration changes to your setup that are away from the vanilla installation? In particular your dashboard setup?
Not sure. What do you mean by “dashboard setup”?
I don’t think we have anything configured out of the ordinary. What might be a bit special is that we aren’t using the dashboard for much except debugging and configuration. We’re using our own developer portal for all the steps I listed. But since they use the same API endpoints as the Tyk Dashboard, I don’t think that’s it.
We’ll bundle it into our next release to fix. For some reason the wrong hash is being attached to a developer record.