Entropi [2486892]

Suggestion Type: New Feature Request

New api endpoints to return paginated list of all users and factions in the game.

 

Why do we need this?

The above post reminded me of this: there's no way to get a list all users or factions in the game from the api without performing what is essentially an enumeration attack on the game to iterate through all the possible ids.

 

What needs to be done?

Using v1 as an example, something like https://api.torn.com/torn/?selections=users&key={key}&page={number} which returns a response along the lines of:

 

{
    "max_page": number,
    "users": [
        {
            "id": number,
            "name": string,
            "signup": timestamp,
            "level": number,
            "faction_id": number|null,
            "faction_name": string|null,
            "last_action": {
                "status": string,
                "timestamp": number
            },
            "status": {
                "description": string,
                "details": string,
                "state": string,
                "until": number
            }
        },

 

        // ... (100 or something results per page)
    ]
}

 

Similarly for factions https://api.torn.com/torn/?selections=factions&key={key}&page={number} and:

 

{
    "max_page": number,
    "factions": [
        {
            "id": number,
            "name": string,
            "tag": string,
            "age": number,
            "leader_id": number,
            "leader_name": string,
            "coleader_id": number|null,
            "coleader_name": string|null,
            "members": number,
            "capacity": number,
            "best_chain": best_chain,
            "respect": number,
            "rank": {
                "level": number,
                "name": string,
                "division": number,
                "position": number,
                "wins": number
            }
        },

 

        // ... (100 or something results per page)
    ]
}

 

Obviously the exact data returned probably needs a bit more thought put into it but this should be good enough for an example.

 

Drawbacks?

Shouldn't be anything major with the minimal concept. It's something which is already possible, just in a rather ugly manner. If there were more complex filtering options, especially for users, that might present an advantage to scripters depending on what those filtering options were (e.g. for finding chain targets).

JKyte [2417425]

An endpoint to get just the ids of active players would be great. R+

tiksan [2383326]

Or a tarball that’s updated daily with the data of all users would be even better.

Entropi [2486892]

Suggestion Type: New Feature Request

New api endpoints to return paginated list of all users and factions in the game.

 

Why do we need this?

The above post reminded me of this: there's no way to get a list all users or factions in the game from the api without performing what is essentially an enumeration attack on the game to iterate through all the possible ids.

 

What needs to be done?

Using v1 as an example, something like https://api.torn.com/torn/?selections=users&key={key}&page={number} which returns a response along the lines of:

 

{
    "max_page": number,
    "users": [
        {
            "id": number,
            "name": string,
            "signup": timestamp,
            "level": number,
            "faction_id": number|null,
            "faction_name": string|null,
            "last_action": {
                "status": string,
                "timestamp": number
            },
            "status": {
                "description": string,
                "details": string,
                "state": string,
                "until": number
            }
        },

 

        // ... (100 or something results per page)
    ]
}

 

Similarly for factions https://api.torn.com/torn/?selections=factions&key={key}&page={number} and:

 

{
    "max_page": number,
    "factions": [
        {
            "id": number,
            "name": string,
            "tag": string,
            "age": number,
            "leader_id": number,
            "leader_name": string,
            "coleader_id": number|null,
            "coleader_name": string|null,
            "members": number,
            "capacity": number,
            "best_chain": best_chain,
            "respect": number,
            "rank": {
                "level": number,
                "name": string,
                "division": number,
                "position": number,
                "wins": number
            }
        },

 

        // ... (100 or something results per page)
    ]
}

 

Obviously the exact data returned probably needs a bit more thought put into it but this should be good enough for an example.

 

Drawbacks?

Shouldn't be anything major with the minimal concept. It's something which is already possible, just in a rather ugly manner. If there were more complex filtering options, especially for users, that might present an advantage to scripters depending on what those filtering options were (e.g. for finding chain targets).

JKyte [2417425]

An endpoint to get just the ids of active players would be great. R+

tiksan [2383326]

Or a tarball that’s updated daily with the data of all users would be even better.

Lazerpent [2112641]

I was actually going to make a post asking for this later.

 

Just a large dump of all users daily would have so many benefits and likely (drastically) cut down on the number of daily API calls.

splent [2088243]

I still haven't properly looked at the endpoints that are being heavily requested, but one of the things that is on my plate (at some point in the future), is also optimizing heavily requested endpoints and to check with the community what would be the best way to do that.

I will certainly think more deeply about this topic.

 

 

 

Omanpx [1906686]

Suggestion type: New feature request

API endpoint to pull player / faction list for certain HoF categories.

 

Why do we need this?

There are a lot of interesting and useful applications around HoF, from live leaderboards to competitions and player achievement tracking (i am kind of a sucker for data, so probably very biased).

 

What needs to be done?

A new endpoint added, preferably with pagination or some other way to get a specific number of results (can mimic the pagination of HoF in game, or return 100 IDs per page), like https://api.torn.com/torn/?selections=hof&cat={category}&key={key}&page={number}, where {category} can be any category from HoF that publicly lists players / factions. An example response could be:

 

For Networth category:

https://api.torn.com/torn/?selections=hof&cat=networth&key={key}&page={number}

 

{
"page": number,
"hof": [

{

"networth":[
{
"id": number,
"name": string,

"position": number,
"networth": number,
},

...

}

]

}

]
}

 

A similar layout for factions should work as well.

 

Consider any drawbacks of your suggestion: 

Can't really think of any - as long as it's only available for categories that have publicly available names. Current option is to scrape the pages, which is not ideal, but people do it anyway.

Entropi [2486892]

Suggestion Type: New Feature Request

New api endpoints to return paginated list of all users and factions in the game.

 

Why do we need this?

The above post reminded me of this: there's no way to get a list all users or factions in the game from the api without performing what is essentially an enumeration attack on the game to iterate through all the possible ids.

 

What needs to be done?

Using v1 as an example, something like https://api.torn.com/torn/?selections=users&key={key}&page={number} which returns a response along the lines of:

 

{
    "max_page": number,
    "users": [
        {
            "id": number,
            "name": string,
            "signup": timestamp,
            "level": number,
            "faction_id": number|null,
            "faction_name": string|null,
            "last_action": {
                "status": string,
                "timestamp": number
            },
            "status": {
                "description": string,
                "details": string,
                "state": string,
                "until": number
            }
        },

 

        // ... (100 or something results per page)
    ]
}

 

Similarly for factions https://api.torn.com/torn/?selections=factions&key={key}&page={number} and:

 

{
    "max_page": number,
    "factions": [
        {
            "id": number,
            "name": string,
            "tag": string,
            "age": number,
            "leader_id": number,
            "leader_name": string,
            "coleader_id": number|null,
            "coleader_name": string|null,
            "members": number,
            "capacity": number,
            "best_chain": best_chain,
            "respect": number,
            "rank": {
                "level": number,
                "name": string,
                "division": number,
                "position": number,
                "wins": number
            }
        },

 

        // ... (100 or something results per page)
    ]
}

 

Obviously the exact data returned probably needs a bit more thought put into it but this should be good enough for an example.

 

Drawbacks?

Shouldn't be anything major with the minimal concept. It's something which is already possible, just in a rather ugly manner. If there were more complex filtering options, especially for users, that might present an advantage to scripters depending on what those filtering options were (e.g. for finding chain targets).

JKyte [2417425]

An endpoint to get just the ids of active players would be great. R+

tiksan [2383326]

Or a tarball that’s updated daily with the data of all users would be even better.

Lazerpent [2112641]

I was actually going to make a post asking for this later.

 

Just a large dump of all users daily would have so many benefits and likely (drastically) cut down on the number of daily API calls.

splent [2088243]

I still haven't properly looked at the endpoints that are being heavily requested, but one of the things that is on my plate (at some point in the future), is also optimizing heavily requested endpoints and to check with the community what would be the best way to do that.

I will certainly think more deeply about this topic.

 

 

 

Entropi [2486892]

Suggestion Type: New Feature Request

New api endpoints to return paginated list of all users and factions in the game.

 

Why do we need this?

The above post reminded me of this: there's no way to get a list all users or factions in the game from the api without performing what is essentially an enumeration attack on the game to iterate through all the possible ids.

 

What needs to be done?

Using v1 as an example, something like https://api.torn.com/torn/?selections=users&key={key}&page={number} which returns a response along the lines of:

 

{
    "max_page": number,
    "users": [
        {
            "id": number,
            "name": string,
            "signup": timestamp,
            "level": number,
            "faction_id": number|null,
            "faction_name": string|null,
            "last_action": {
                "status": string,
                "timestamp": number
            },
            "status": {
                "description": string,
                "details": string,
                "state": string,
                "until": number
            }
        },

 

        // ... (100 or something results per page)
    ]
}

 

Similarly for factions https://api.torn.com/torn/?selections=factions&key={key}&page={number} and:

 

{
    "max_page": number,
    "factions": [
        {
            "id": number,
            "name": string,
            "tag": string,
            "age": number,
            "leader_id": number,
            "leader_name": string,
            "coleader_id": number|null,
            "coleader_name": string|null,
            "members": number,
            "capacity": number,
            "best_chain": best_chain,
            "respect": number,
            "rank": {
                "level": number,
                "name": string,
                "division": number,
                "position": number,
                "wins": number
            }
        },

 

        // ... (100 or something results per page)
    ]
}

 

Obviously the exact data returned probably needs a bit more thought put into it but this should be good enough for an example.

 

Drawbacks?

Shouldn't be anything major with the minimal concept. It's something which is already possible, just in a rather ugly manner. If there were more complex filtering options, especially for users, that might present an advantage to scripters depending on what those filtering options were (e.g. for finding chain targets).

Show post

JKyte [2417425]

An endpoint to get just the ids of active players would be great. R+

tiksan [2383326]

Or a tarball that’s updated daily with the data of all users would be even better.

Lazerpent [2112641]

I was actually going to make a post asking for this later.

 

Just a large dump of all users daily would have so many benefits and likely (drastically) cut down on the number of daily API calls.

splent [2088243]

I still haven't properly looked at the endpoints that are being heavily requested, but one of the things that is on my plate (at some point in the future), is also optimizing heavily requested endpoints and to check with the community what would be the best way to do that.

I will certainly think more deeply about this topic.

 

 

 

Londo_Mollari [2658150]

If you do this I suggest to provide SQLite export of such infrequently updated data. It's one file, self-documenting, compact, easy to cache, easy to work with.

JKyte [2417425]

An endpoint to get just the ids of active players would be great. R+

Show post

tiksan [2383326]

Or a tarball that’s updated daily with the data of all users would be even better.

Lazerpent [2112641]

I was actually going to make a post asking for this later.

 

Just a large dump of all users daily would have so many benefits and likely (drastically) cut down on the number of daily API calls.

splent [2088243]

I still haven't properly looked at the endpoints that are being heavily requested, but one of the things that is on my plate (at some point in the future), is also optimizing heavily requested endpoints and to check with the community what would be the best way to do that.

I will certainly think more deeply about this topic.

 

 

 

Londo_Mollari [2658150]

If you do this I suggest to provide SQLite export of such infrequently updated data. It's one file, self-documenting, compact, easy to cache, easy to work with.

GreenNipple [2563870]

So you assume everyone uses SQLite? 

tiksan [2383326]

Or a tarball that’s updated daily with the data of all users would be even better.

Show post

Lazerpent [2112641]

I was actually going to make a post asking for this later.

 

Just a large dump of all users daily would have so many benefits and likely (drastically) cut down on the number of daily API calls.

splent [2088243]

I still haven't properly looked at the endpoints that are being heavily requested, but one of the things that is on my plate (at some point in the future), is also optimizing heavily requested endpoints and to check with the community what would be the best way to do that.

I will certainly think more deeply about this topic.

 

 

 

Londo_Mollari [2658150]

If you do this I suggest to provide SQLite export of such infrequently updated data. It's one file, self-documenting, compact, easy to cache, easy to work with.

GreenNipple [2563870]

So you assume everyone uses SQLite? 

Londo_Mollari [2658150]

You can't? How so?

Hemicopter [2780600]

Suggestion type:
New feature request

What needs to be done:
Add API endpoint for historical API key usage /key?selections=log

Why do you need this:
This way one can check how many requests were done with your key, if there are certain periods where it was used more/less, and if it was abused for purposes the user did not expect. 

Consider any drawbacks of your suggestion:

We can currently see live logs from the API key view, so this data is somewhat available and not new. 

The live view lists uncensored IPs, but I think this can/should not be stored historically. (As login logs also are censored)

Example:

{
    "requests": [

    {
        "request_id": string, 

        "request_url": string,

        "request_comment": string,
        "request_time": number,
        "request_result": number, // I'm thinking error codes, but there is no "OK" code
        "request_ip": string,

    },

    ...

    ]
}

Hemicopter [2780600]

Suggestion type:
New feature request

What needs to be done:
Add API endpoint for historical API key usage /key?selections=log

Why do you need this:
This way one can check how many requests were done with your key, if there are certain periods where it was used more/less, and if it was abused for purposes the user did not expect. 

Consider any drawbacks of your suggestion:

We can currently see live logs from the API key view, so this data is somewhat available and not new. 

The live view lists uncensored IPs, but I think this can/should not be stored historically. (As login logs also are censored)

Example:

{
    "requests": [

    {
        "request_id": string, 

        "request_url": string,

        "request_comment": string,
        "request_time": number,
        "request_result": number, // I'm thinking error codes, but there is no "OK" code
        "request_ip": string,

    },

    ...

    ]
}

Lazerpent [2112641]

I presume the request_ips are already stored long-term, but what if this endpoint provided a hash of the IP?

That would allow for the identification of duplicates while also maintaining somewhat long-term IP privacy

JKyte [2417425]

New Feature Request: add 'rankedwarassists' to public stats.

 

Currently we have attacks and assists as their own data points (attackswon and attacksassisted), but we only have rankedwarhits. Adding RW assists would bring consistency to the personal stats, and make my life easier when calculating RW payouts based on hits and assists.