splent [2088243]

Hi everyone,

Few new selections are now available in the API v2:

• 'user' -> 'bounties' returning the details about user's bounties
• 'torn' -> 'bounties' returning details about all bounties
• 'user' -> 'jobranks' returning user's job positions (Minimal API key required, available only to yourself)

 

These selections can also be tried through Swagger (if you're not seeing them, make sure to clear cache on both Swagger page and openapi.json file).

Thanks!

Wolverine [1971836]

Hi, do you know if there is a chance in the future to get the number of FHC used with API v2?

 

splent [2088243]

Hey, if that gets added to player statistics then sure, it shouldn't be a problem.

I can't help you with adding that to the profile statistics page though. You know the drill with the suggestions! :D

splent [2088243]

Hey all, 

It looks like 'user' -> 'networth' selection was causing a lot of stress on db5, so as a result the inventory page was loading slower or breaking sometimes.

For this reason I temporarily added 1 hour global cache (can't be bypassed by 'timestamp' or other query parameters) to this selection.

If necessary, we might have to increase the cache duration a little bit more, but I'm really hoping this will suffice.

Thanks for understanding!

splent [2088243]

Hey all, 

It looks like 'user' -> 'networth' selection was causing a lot of stress on db5, so as a result the inventory page was loading slower or breaking sometimes.

For this reason I temporarily added 1 hour global cache (can't be bypassed by 'timestamp' or other query parameters) to this selection.

If necessary, we might have to increase the cache duration a little bit more, but I'm really hoping this will suffice.

Thanks for understanding!

Kwack [2190604]

Is there a way to get the timestamp of when it was cached? I assume since it's a global cache, adding the timestamp selection probably won't give us this info. 

 

Is this information that we could get available to sections with global caches going forward? Makes it a lot better to show the user when the data was updated last if we can't keep it live anymore

Microbes [2622522]

'torn' -> 'logtypes' broken?

 

https://api.torn.com/v2/torn/?selections=logtypes&key=key&id=120

 

supposed to return "2FA SMS code sent" logs yet it gave a completely unrelated response? The same goes for all IDs.

 

{"logtypes":[{"id":5110,"title":"Honor awarded"},{"id":5120,"title":"Medal awarded"},{"id":5130,"title":"Rank change"},{"id":5140,"title":"Title change"},{"id":5150,"title":"Honor bar changed"}]}

 Thanks.

Microbes [2622522]

'torn' -> 'logtypes' broken?

 

https://api.torn.com/v2/torn/?selections=logtypes&key=key&id=120

 

supposed to return "2FA SMS code sent" logs yet it gave a completely unrelated response? The same goes for all IDs.

 

{"logtypes":[{"id":5110,"title":"Honor awarded"},{"id":5120,"title":"Medal awarded"},{"id":5130,"title":"Rank change"},{"id":5140,"title":"Title change"},{"id":5150,"title":"Honor bar changed"}]}

 Thanks.

Omanpx [1906686]

Isn't logtypes supposed to return all log type IDs and names, not the logs itself? I think you want user / log in api V1 for this.

splent [2088243]

Hey all, 

It looks like 'user' -> 'networth' selection was causing a lot of stress on db5, so as a result the inventory page was loading slower or breaking sometimes.

For this reason I temporarily added 1 hour global cache (can't be bypassed by 'timestamp' or other query parameters) to this selection.

If necessary, we might have to increase the cache duration a little bit more, but I'm really hoping this will suffice.

Thanks for understanding!

Kwack [2190604]

Is there a way to get the timestamp of when it was cached? I assume since it's a global cache, adding the timestamp selection probably won't give us this info. 

 

Is this information that we could get available to sections with global caches going forward? Makes it a lot better to show the user when the data was updated last if we can't keep it live anymore

splent [2088243]

Hey all, 

It looks like 'user' -> 'networth' selection was causing a lot of stress on db5, so as a result the inventory page was loading slower or breaking sometimes.

For this reason I temporarily added 1 hour global cache (can't be bypassed by 'timestamp' or other query parameters) to this selection.

If necessary, we might have to increase the cache duration a little bit more, but I'm really hoping this will suffice.

Thanks for understanding!

Kwack [2190604]

Is there a way to get the timestamp of when it was cached? I assume since it's a global cache, adding the timestamp selection probably won't give us this info. 

 

Is this information that we could get available to sections with global caches going forward? Makes it a lot better to show the user when the data was updated last if we can't keep it live anymore

splent [2088243]

Hey, this change is now live.

I added a new field "timestamp" to 'user' -> 'networth' selection in API v1.

You may need to wait up to an hour for the change to be visible (depending on when was the data requested last time).

On a side note - I also removed "defaultSelection" from appearing in all lookup selections.

Thank you.

splent [2088243]

Hey all, 

It looks like 'user' -> 'networth' selection was causing a lot of stress on db5, so as a result the inventory page was loading slower or breaking sometimes.

For this reason I temporarily added 1 hour global cache (can't be bypassed by 'timestamp' or other query parameters) to this selection.

If necessary, we might have to increase the cache duration a little bit more, but I'm really hoping this will suffice.

Thanks for understanding!

Kwack [2190604]

Is there a way to get the timestamp of when it was cached? I assume since it's a global cache, adding the timestamp selection probably won't give us this info. 

 

Is this information that we could get available to sections with global caches going forward? Makes it a lot better to show the user when the data was updated last if we can't keep it live anymore

splent [2088243]

Hey, this change is now live.

I added a new field "timestamp" to 'user' -> 'networth' selection in API v1.

You may need to wait up to an hour for the change to be visible (depending on when was the data requested last time).

On a side note - I also removed "defaultSelection" from appearing in all lookup selections.

Thank you.

splent [2088243]

Hey all, 

It looks like 'user' -> 'networth' selection was causing a lot of stress on db5, so as a result the inventory page was loading slower or breaking sometimes.

For this reason I temporarily added 1 hour global cache (can't be bypassed by 'timestamp' or other query parameters) to this selection.

If necessary, we might have to increase the cache duration a little bit more, but I'm really hoping this will suffice.

Thanks for understanding!

Kwack [2190604]

Is there a way to get the timestamp of when it was cached? I assume since it's a global cache, adding the timestamp selection probably won't give us this info. 

 

Is this information that we could get available to sections with global caches going forward? Makes it a lot better to show the user when the data was updated last if we can't keep it live anymore

splent [2088243]

Hey, this change is now live.

I added a new field "timestamp" to 'user' -> 'networth' selection in API v1.

You may need to wait up to an hour for the change to be visible (depending on when was the data requested last time).

On a side note - I also removed "defaultSelection" from appearing in all lookup selections.

Thank you.

Marches [3131483]

It's a somewhat bigger change, but would there be value in (one day!) adding something like to all requests in v2? That way, you always know if you've accidentally hit a cache.

 

Either way, love the changes you've been making. Thanks!

splent [2088243]

Hey all, 

It looks like 'user' -> 'networth' selection was causing a lot of stress on db5, so as a result the inventory page was loading slower or breaking sometimes.

For this reason I temporarily added 1 hour global cache (can't be bypassed by 'timestamp' or other query parameters) to this selection.

If necessary, we might have to increase the cache duration a little bit more, but I'm really hoping this will suffice.

Thanks for understanding!

Kwack [2190604]

Is there a way to get the timestamp of when it was cached? I assume since it's a global cache, adding the timestamp selection probably won't give us this info. 

 

Is this information that we could get available to sections with global caches going forward? Makes it a lot better to show the user when the data was updated last if we can't keep it live anymore

splent [2088243]

Hey, this change is now live.

I added a new field "timestamp" to 'user' -> 'networth' selection in API v1.

You may need to wait up to an hour for the change to be visible (depending on when was the data requested last time).

On a side note - I also removed "defaultSelection" from appearing in all lookup selections.

Thank you.

Marches [3131483]

It's a somewhat bigger change, but would there be value in (one day!) adding something like to all requests in v2? That way, you always know if you've accidentally hit a cache.

 

Either way, love the changes you've been making. Thanks!

splent [2088243]

Hey so there are basically 2 different caches. One is request specific cache (we call this internally "service cache") and second is selection specific cache (what I usually refer to as "global" cache).

It is a "known thing" (it's mentioned nowhere in the official documentation though) to bypass request cache by passing different values in "timestamp" query parameter (or to change any other parameters). That is also why "timestamp" selection exists across all types (user, faction, property, torn, etc.), so you can know when was something cached. 

If you can do this quickly enough, you can see the request cache working in this example: 

1. Select 'money,timestamp' from user without any additional parameters, like so: https://api.torn.com/user/?selections=money,timestamp&key=
2. Send few $$ to a friend

3. Repeat the request above, the money and timestamp values should still be the same
4. Request a slightly modified request to see new values, e.g. https://api.torn.com/user/?selections=money,timestamp×tamp=1232&key= (this one should now have different timestamp and money fields)

5. Eventually (30s after the initial request), the response from the initial request will get updated as well

But again, this is just an example and it is crucial that you can do this quickly enough.

So for this request specific cache, you can utilize "timestamp" selection to know if you're getting cached data and when was the data cached.

This type of cache exists to reduce unnecessary load on the server.

--

However, the global cache is a little bit different. It will return the same response regardless of the input parameters, so depending if it is a private or public selection it will return the same response for everyone. For this I'm happy to add specific selection's timestamp. 

Currently, global cache is used only on 3 selections:

• 'user' -> 'networth' in API v1
• 'user' -> 'bazaar' in API v1
• 'racing' -> 'records' in API v2

 

For now cache timestamp is only available in 'user' -> 'networth' selection simply because the other 2 selections return arrays and I need to do some refactoring before I can provide cache timestamp on them, but yes - I'll definitely provide this on any future global caches.

--

Tldr; You can use "timestamp" selection to know when something was cached, otherwise yes - I will provide specific cache timestamp in the future for globally cached selections.

Hopefully this was not unnecessary over explaining, but will actually help you understand how everything's working better. 

Thanks!