Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Introduction

Tornium is a website and Discord with integrating userscripts to automate and assist players, faction leaders, and Discord server administrators. Tornium includes this limited list of features:

  • Discord user verification: Link your Discord account to your Torn account through Torn’s Discord server for seamless integration with servers’ access control
  • User stat estimation: Estimate user stats through historical and statistical modeling.
  • Custom Lua notifications: Setup custom or pre-written Lua-based notifications for various in-game events through the Torn API
  • OD tracking: Monitor overdoses of your faction members
  • OC tracking: Monitor various aspects of your faction’s organized crimes

For a more comprehensive list of features, see the navigation in the sidebar.

Links

Contributing

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change. For more information, see the contributing guide on GitHub.

License

The Tornium documentation (and the majority of the source code) are released under the GNU General Public License v3.0. For the source code, be sure to read the license headers and license files as different sections of the codebase may be licensed differently.

How to Report

How should you report bugs and ask questions? This document describes the do’s and don’ts of reporting bugs and asking for help for things related to Tornium. Effectively asking questions and reporting bugs allows for easier diagnoses and responses and saves everyone time.

Reporting Bugs

Reporting bugs in a coherent manner is important to avoid wasting everyone’s time. When reporting a bug, you should be sure that the bug is reproducible and is observable. Be specific!

  1. A one sentence description of the bug.
  2. A description of what was supposed to happen.
  3. A description of what actually happened.
  4. Screenshots of behavior.
  5. Where this bug occurred (e.g. a URL to Tornium).
  6. When this occurred (including your timezone if you stated the time in local time).
  7. An error message if one is indicated.

If this bug occurred on the Tornium website, please also include the device, the browser, etc. the bug occurred on.

Asking Questions

Asking questions regarding Tornium should follow a specific format. Be specific!

  1. A one sentence overview of the question.
  2. A description of what you wanted to do.
  3. A description of what you tried.
  4. An error message if one was indicated.

Data Use and Storage Policy

This document supplements Tornium’s Privacy Policy to provide more details regarding Tornium’s storage and use of user data. Tornium offers toggles on the user settings page for you to enable/disable the usage of your API key for certain features. You can toggle the following usage of your API key:

  • Share CPR: When enabled, this will collect the CPR of OCs in recruiting status (even if you’re not in them) with your API key and share those CPRs with members of your faction.
  • Share opponent stats: When enabled, this will collect the stat scores of users you attack with your API key and of users who attack you and share those stat scores with either all Tornium users or members of your faction through the stat database.
  • Share overdosed drug: When enabled, this will collect the drug you overdosed upon from your user logs and share that data with your faction.
  • Share public data: When enabled, this will collect public data on other Torn users, factions, stocks, etc. and share that data with all users of Tornium.

If you have any questions or concerns regarding how Tornium stores your data, please create a ticket in Tornium’s support server. If you would like your data in Tornium to be deleted, send an in-game mail to tiksan [2383326].

API Keys

We persistently store Torn API keys to retrieve data from Torn regarding your user and potentially your faction, company, and other data depending on features enabled and permissions granted to you in-game. Your API key(s) will only be used for features regarding your account, regarding your faction if you have the API Access permission, regarding any Discord servers in which you are an admin. No other user will be able to see your API key(s).

User Attacks

We collect user attacks to calculate the stat scores of the opponent for the stat database. This data (except for related data in the stat database) is not stored persistently. Your attacks cannot be accessed by anyone. This feature for your account can be disabled to not use your API key in Tornium’s user settings under Share opponent stats.

User Battle Stats

We collect the battle stats of users who are signed into Tornium and potentially their faction members through TornStats to calculate stat scores from attacks and to calculate estimated respect for the chain list generator and stat database. All users’ battle stats are NOT shared publicly with anyone nor do we view them. This data is stored persistently.

User CPR

We collect the Organized Crime 2.0 success chance of users for each OC position for each OC type if the user’s faction has migrated to Organized Crimes 2.0. This data can be accessed by your faction’s members with the “Manage Organized Crimes” permission. This feature for your account can be disabled in Tornium’s user settings under Share CPR.

User Logs

If you have a full access API key on Tornium, we may collect your user logs for the following log categories and reasons:

(category) Item use drug: This data is used for overdose drug detection. The data on the drug overdosed on can be accessed by your faction’s members with faction API access. This feature for your account can be disabled in Tornium’s user settings under Share overdosed drug.

Faction Attacks

We may collect your faction attacks for potential retaliations, for the chain timer, for updating the stat database. This data (except for related data in the stat database) is not stored persistently. Your faction attacks cannot be accessed by anyone.

Faction Crimes

We collect your faction organized crimes for related notifications (e.g. when an organized crime is delayed). This data is stored persistently and can be accessed by any member of your faction with the “Manage Organized Crimes” permission.

Faction Armory

We collect your faction armory data for notifications when the armory is low on stock for specific item(s), for overdose drug detection, and for armory usage reporting. This data is stored persistently and can be accessed by any member of your faction with faction API access permissions.

Faction Funds

We collect your faction funds data to handle withdrawal requests for members against the faction’s vault. This data (except for related data in withdrawal requests) is not stored persistently. Your faction funds cannot be accessed by anyone.

Faction Positions

We collect your faction positions to handle permissions on Tornium and to determine which faction members can access data through the API. This data is stored persistently. Your faction positions can not be directly accessed by anyone with the exception of members viewing which members have faction API access and banking permissions.

Faction Overdoses

We collect your faction overdoses for overdose notifications. This data is stored persistently. Your faction overdoses cannot be accessed by anyone, but notifications for faction overdoses may be sent to the linked Discord server.

General Geolocation

We log the full IP addresses used to log in to accounts and retain that data for account security. This data is stored persistently. We also log IP addresses for all requests on a rolling basis for monitoring purposes. This data can only be accessed by Tornium administartor(s).

General Torn Data

We collect general, public Torn data (such as all items) to keep our database up-to-date using the API keys who have toggled Share public data in Tornium’s user settings. This data is stored on a persistent basis. This data can be accessed any user. Using your API key to collect this data can be disabled in Tornium’s user settings under Share public data.

Install Bot to Discord Server

In this tutorial, we will be installing the Tornium Discord bot to a Discord server. Installing the bot will require at least the manage server permission on the Discord server, but configuring the bot for the Discord server will require additional permissions: at least administrator permissions on the Discord server.

Adding the Bot

First, we will be adding the bot to the Discord server. Installation can be done through this Discord invite link with the minimal permissions required. This Discord invite link will open a Discord page for you to select the server to invite the bot to. After pressing continue, Discord will list the permissions you are granting the bot in the selected server. You will then press “Authorize” on this page to invite the bot to the selected Discord server.

At this point, the Discord bot will be added to the selected Discord server. We can verify that the bot has been added to the server by finding Tornium in the member list of the server. Now that the bot has been added to the server, we can now start configuring the bot for this server.

Configuring the Bot

Now that the bot has been added to the Discord server, you will need to wait for Tornium to store the Discord server in its database. If you have administrator permissions on the Discord server, you will be able to see that the bot has been added to the database when the Discord server is listed on the Server Selector on Tornium’s website.

Once the Discord server is listed on the “Server Selector”, we can now start configuring features for the Discord server. You will need to select the specific Discord server with the “Edit Server” button. After pressing the “Edit Server” button, you will be redirected to the main bot configuration page for the selected Discord server. On this page, you will be able to set up various features for the bot on this Discord server.

For information on configuring specific features, follow these tutorials:

Link Server and Faction

Many faction-oriented features require a link to be created between the faction and the Discord server for security purposes. In this tutorial, we will be linking your faction and a Discord server together. First of all, to proceed, you will need have AA permissions in your faction and will have to have administrator permissions in the Discord server.

First, we will be retrieving the IDs of the faction and the Discord server. As you retrieve these values, you should temporarily save them in a file for you to access as we progress through this tutorial. You can find the ID of the faction by searching for the faction by name in-game and the ID will be in the URL after &ID=. For example, if you search for the faction Natural Selection, the faction’s URL is https://www.torn.com/factions.php?step=profile&ID=9533 and the ID of the faction is 9533. For the Discord server’s ID, you can follow Discord’s guide to get this.

Now that you have retrieved your faction ID and the Discord server ID, we can start by setting the server ID for your faction. You will only be able to set the server ID for the faction you are currently in and this will require you to have AA permissions in the faction. On the Tornium faction bot page, you can paste the Discord server ID under the Guild ID input box. Make sure you press Enter after inputting the server ID so that the server ID of the faction will be updated. If you refresh the page, the Guild ID input box should now show the ID of the Discord server you previously filled in.

After setting your faction’s server ID, we can now add the faction’s ID to the server’s list of factions. On the Tornium server selector, select the server which you’ve previously copied the ID of. At the top of this dashboard of server-related configurations is a section about factions in the server. Paste the previously copied ID of your faction into the input box in this section. Upon pressing the Add button, the faction name should appear underneath the input box. Next to the faction name will be a checkmark or cross-mark indicating either successful or unsuccessful linking respectively. If a cross-mark appears next to your faction’s name, go back through the previous steps and make sure they were done properly.

Once the checkmark appears next to your faction name, your faction and Discord server have been properly linked together. And now Discord features for your faction will now begin working and can be configured by you or anyone with administrator permissions in the server.

Setup Verification

In this tutorial, we will be setting up verification in a Discord server. Verification will allow for the identification of Discord server members as Torn users. Once a user is verified on the official Torn Discord server, Tornium will be able to identify the user’s Torn account and modify the user’s nickname and roles in the Discord server according to the server’s configuration. Before starting, you will need to have done the following steps:

  1. Bot installation: Install the bot in your Discord server
  2. (Optional) Faction-server linking: Link your faction and Discord server together

NOTE: Due to Discord’s permission system, Tornium is unable to verify the Discord server owner or any member of the server with a role higher than the bot’s highest role. Verification of these members will have be performed manually by a server administrator.

First, we will open the Discord server’s verification dashboard. Select your Discord server on Tornium’s server selector to open your server’s dashboard. Then the verification dashboard can be found under the Verification header of the server dashboard by pressing the Go To Verification Settings button. This verification dashboard contains all the configuration options for verifying members of your Discord server.

All parts of this tutorial are optional after this point. Different features can be used to configure your Discord server in different ways. For more in-depth information on verification, visit the verification reference page. Once your Discord server’s verification is configured, you can enable verification with the global verification toggle found at the top of the server’s verification dashboard.

Minimal Verification Configuration

Now that you’re on the Discord server’s verification dashboard, we can start configuring the common, minimal configuration for verification: roles for verified members and roles for faction members.

First, we will be setting the roles given to members of the Discord server who are verified under Verified Roles. In this section, you can select multiple (or none) roles to be assigned to these members. You can ensure that the settings have saved by refreshing the page and checking the roles are still listed.

Now, we can set up roles to be assigned to members of the Discord server who are in certain factions. Under the Faction Verification section, there is an input box named Torn Faction ID. Here you can enter the ID of the faction(s) for which Tornium should assign roles and then press the Add button next to the input. This will create a card under the Faction Verification section titled with the faction ID you’ve just entered. You can assign the roles to be assigned to Discord server members in this faction on the input within this card. Once again, you can refresh the page once adding the roles to ensure that the settings have been saved properly.

At this point, we have now set up roles to be assigned to members of your Discord server who are verified and in certain factions. Many Discord server consider this to be sufficient.

Slash Commands

Once you’ve completed the minimal verification configuration, you can start using the two slash commands provided by Tornium to verify the members of the Discord server. First, you should ensure the global toggle for verification has been enabled, found at the top of the verification dashboard of the Discord server, to allow for verification of server members.

The /verify slash command allows server members to verify themselves. By including a mention of another member, /verify member:@Chedburn will verify another member.

The /verifyall slash command is intended for server administrators to verify all members of the Discord server. This can take a few minutes to occur, especially on larger servers.

Daily Verification

Tornium supports verifying all members of the Discord server at a pre-determined time every day. Before we start, ensure you are on the verification dashboard for the Discord server. If you haven’t already, you will need to set up at least the minimal verification configuration above.

First, it is recommended but not essential to enable the Discord log channel. The log channel can be found at the top of the verification dashboard for the Discord server under the Basic Verification Configuration section. This channel should be set to a channel in the Discord server restricted to server administrators. Once this log channel is set, messages regarding successful/failed verification of server members during the daily verification will be sent here.

Now, you will need to enable the feature by pressing the Enable button for daily verification under the Automatic Verification section on the verification dashboard. In the text above this button, you can also find the time daily verification will run on your Discord server.

At this point, we have set up daily verification of server members which will run automatically at the pre-determined time every day.

Verification-on-Join

Tornium supports automatically verifying members of the Discord server as they join the server. Before we start, ensure you are on the verification dashboard for the Discord server. If you haven’t already, you will need to set up at least the minimal verification configuration above.

First, it is recommended but not required to set up a channel members will first see as they join the Discord server – known as the “jail channel”. This will also be the channel used in the Discord invitation and is typically a channel at the top of the Discord server. The jail channel can be found at the top of the verification dashboard for the Discord server under the Basic Verification Configuration section. Once the jail channel for the Discord server is set, messages regarding successful/failed verification and verification instructions will be sent in this channel as members join the Discord server.

Now, you will need to enable the feature by pressing the Enable button for verification-on-join under the Automatic Verification section on the verification dashboard.

At this point, new members joining the Discord server will automatically be verified.

More Configuration

There are further configuration options that provide more customization for verification of Discord server members on Tornium including customizable nicknames. For more information, see the verification reference page.

For example, it is suggested to give all bots a shared “Bot” role and add that bot role as an exclusion role to prevent Tornium from attempting to verify bots.

Setup Organized Crimes

WARNING: This series of features is in active development and will change as time passes.

Setup Notifications

In this tutorial, we will be setting up notifications in a Discord server. Notifications are a powerful, complex tool allowing custom notifications of in-game actions and events. You can build your own notifications triggers (soon; this is not yet released) or you can use pre-built, official notification triggers. This tutorial will only go over how to setup pre-built, official notification triggers; for more information on notifications and notification triggers, visit the notification reference and the notification trigger reference.

WARNING: As stated in Tornium’s ToS, you are not allowed to use this feature to disrupt Tornium. Intentionally malicious use of this feature is not permitted.

Terminology

Notification Trigger: generic user-provided code providing the logic and message for notifications when installed

Official Notification Trigger: notification triggers provided by Tornium for use by everyone

Restricted Notification Trigger: notification triggers utilizing non-public information (see the notification trigger reference)

Notification: installed notification triggers configured for certain parameters

Parameters: values in notification triggers defined by end-users determining the behavior of the notification

Example

For example, a notification to send a message when a certain stock is below a certain price would look like the following:

Notification Trigger: the code that checks the stock price and the message it’ll send when the stock price is below the target price

Parameters: the stock to check (e.g. FHG) and the target stock price (e.g. $770)

Then whenever the stock is below the target stock price, the bot will determine that the notification trigger has been activated and will send a message in a specific channel with the message the notification trigger provides.

Setting up a Notification

Now that you understand what notifications and notification triggers are, we can set up an official notification trigger. First you will need to view Tornium’s list of the official notification triggers under Notification > Notification Triggers. The section under Official Notification Triggers lists the official triggers for use by anyone. For information on each of the official notification triggers, visit the notification trigger reference.

Once you find the notification trigger you want to install, you can press the plug button next to the trigger to add the trigger to a Discord server you are an admin in (Tornium’s bot must be in this server). This will open a page providing a full description of the notification trigger. You will need to select which Discord server you will install the notification trigger to. Upon pressing “Add Trigger”, you will be sent to a page to configure the notification trigger. Here, you will select the notification channel, the resource ID, and a one-shot flag and then you will fill in the notification trigger’s parameters. This will be described in depth below:

The notification channel is the Discord channel where messages for the notification trigger will be sent when the trigger is activated. The resource ID is the ID of the user, faction, etc. the notification trigger will be acting upon. The one-shot flag determines how many times the notification trigger can be activated before the notification is deleted, but you should follow the instructions provided in the notification trigger’s description when setting this value. The notification triggers are parameters provided by the developer of the notification trigger to provide additional configuration, and once again you will need to follow the instructions provided in the description of the notification trigger.

Once the notification trigger has been configured, you can press the “Setup Trigger” button for the notification trigger to be installed into the Discord server. At this point, the notification will now be running until the notification is deleted or disabled. For more information on notifications and notification triggers, visit the notification reference and the notification trigger reference.

Bot Configuration

TODO

Setup Banking

In this tutorial, we will be setting up banking for a faction in a Discord server. Tornium banking will allow faction members to request funds to be withdrawn from their vault balance and sent to them. Once the vault request has been made, faction bankers will have an hour to send the money through the message generated by the bot before the request is cancelled. Before starting, you will need to have completed the following steps:

  1. Bot installation: Install the bot in your Discord server
  2. Faction-server linking: Link your faction and Discord server together
  3. (Recommended) Setup verification: Set up verification in your Discord server using Tornium

First, we’ll need to set up the Discord channel and role to use for banking. The banking channel is where the bot sends vault requests in the Discord server, and therefore it is suggested that the channel is configured to only allow bankers of that faction access to that channel. The banker role in the Discord server is pinged in the previous channel when a vault request is sent and should be given to members of the faction with banking permissions.

Banking Configuration

Now that we have a channel and role set up for banking, we will open the Discord server’s dashboard. Select your Discord server on Tornium’s server selector to open your server’s dashboard. The section for banking can be found under the Faction Banking header. This faction banking section contains all the configuration options for banking for factions in your Discord server.

Find your faction’s name in this section. Next to your faction’s name will be two select boxes for the banking channel and the banking role respectively. In the first select box, choose the Discord channel for banking you had previously created. And in the second select box, choose the Discord role for banking you’d created above. You can ensure that the settings have saved by refreshing the page and checking the roles are still listed. At this point, we have now set up faction banking for your Discord server. For more information, see the banking reference page.

Slash Commands

Once you’ve completed the banking configuration, you can start using the two main slash commands provided by Tornium for banking: /withdraw and /cancel.

The /withdraw slash command allows faction members to request money from their faction balance. When withdrawing money, the bot will check their vault balance in their current faction before sending a message in the configured channel and ping the configured role.

The /cancel slash command allows faction members to cancel their most recent vault request. By providing a withdrawal ID, you can cancel previous vault requests.

Setup Overdose Reporting

In this tutorial, we will be setting up overdose reporting for a faction in a linked Discord server. This will send notifications when a member of the faction overdoses. Before starting, you will need to have completed the following steps:

  1. Bot installation: Install the bot in your Discord server
  2. Faction-server linking: Link your faction and Discord server together
  3. Create a channel to use for overdose notifications.

Overdose Reporting Configuration

Now that we have a faction and server linked and channel set up for notifications, we will open the Discord server’s dashboard. Select your Discord server on Tornium’s server selector to open your server’s dashboard. The section for overdose notifications can be found under the Faction Overdoses header. This faction overdose section contains all the configuration options for overdose notifications for factions in your Discord server.

Find your faction’s name in this section. Next to the faction’s name, there will be two select boxes for the overdose channel and the overdose policy respectively. In the first select box, choose the Discord channel you’d previously created. And in the second select box, choose one of the two policy options:

  1. Daily: A daily report will be sent around midnight TCT listing all overdoses over the last 24 hours.
  2. Immediate: A notification will be sent as the overdoses are noticed.

You can ensure that the settings have saved by refreshing the page and checking the roles are still listed. At this point, we have now set up faction banking for your Discord server. For more information, see the overdose notification reference page.

Generating a Chain List

In this tutorial, we will be generating a chain list: a list of targets fulfilling certain criteria defined by you. These targets can be used to hit certain respect targets while your faction is chaining. Before generating a chain list, you will need to have one of the following:

  1. You should have signed into Tornium with an API key. You can do this through the login page.
  2. OR… You should be in a faction where a leader has provided the stats for faction members. You can check this on the faction members page under your username. If you have a “battlescore”, you’re good to go. Otherwise, you’ll need to do option #1.

WARNING: The chain list generator may provide out-of-date data, especially for active players.

First, we will need to configure the chain list generator to determine which types of targets will be provided. Tornium supports the following configuration options:

  • Difficulty range: The range in fair fight the targets should give you when attacked. The higher the fair fight (3x is the maximum in-game), the higher the respect the target will give and the more difficult the attack will be.
  • Level range: The range in levels the targets should be. The higher the level, the higher the respect the target will give.
  • Sort by: The order in which targets are generated.
  • Limit: The maximum number of targets provided.
  • Inactive only: Only targets that should be inactive will be provided.
  • Factionless only: Only targets that should not be in the faction will be provided.

Now that the chain list generator has been configured, we can press the Generate Chain List button. After a few seconds, the chain list will be loaded into a series of “cards” on mobile devices and a table on desktop devices. By clicking on the targets’ name, the target’s profile on Torn will be opened in a new tab. The generated chain list will also provide the fair fight and respect the target should provide if attacked.

For more information on the chain list generator, see the chain list generator reference page.

Install Tornium Estimate Userscript

In this tutorial, we will be installing and setting up the Tornium stat estimation userscript. This userscript will show users’ stats according to the historical stat database or the statically-modeled stat estimates.

Before starting, ensure you have a userscript manager installed on your browser. The recommended and tested userscript managers are the following:

NOTE: TornPDA may work for you on the built-in userscript manager, but some people will have issues with TPDA injecting the userscript due to a bug with TPDA. Due to this and the lack of development tooling to debug issues on TPDA, support for TPDA is as-is. I will try to keep it running, but I can only say that it only works for me on my phone.

Once the userscript manager has been installed, on the browser with the userscript manager, navigate to the userscript and press the Raw button (or visit this link). If your userscript manager is installed properly, this will automatically install the userscript and show a confirmation page from the userscript manager. If you’re installing the userscript onto TornPDA, make sure that the injection time is set to the end.

You can ensure the userscript has been installed by visiting any user’s profile page and pressing the Estimate Settings button (see the below image). If you are on a mobile device, the label on the button will be hidden by Torn and only the icon on the image will be shown.

By pressing that button, you will be taken the page to configure this userscript (similar to the below image).

You will need to press the Connect button to authenticate with Tornium. This will redirect you to Tornium where you can either sign in with an API key or through Discord (which doesn’t require an API key but does require you to have linked Torn and Discord accounts). After signing into Tornium, you can authorize the userscript to make API calls against your Tornium user.

Once authorized, you will be redirected back to Torn. If the userscript has successfully authenticated with Tornium, the authentication status in the userscript’s settings will say Connected.

WARNING: Due to security limitations of userscripts and userscript managers, in an attempt to keep your Tornium account secure, you MUST re-authenticate every week. This can be done in the userscript’s settings.

For more information on this userscript, see the Tornium estimate reference.

How to setup 2FA?

This guide shows you how to set up 2FA for your Tornium account using an authenticator app on your phone.

  1. Install a authenticator app.
  2. Visit Tornium settings.
  3. Under the “Two-Factor Authentication” section, enable 2FA.
  4. Scan the QR code with the authenticator app.
  5. Enter the code generated by the authenticator app for Tornium and verify the code.

Now, 2FA has been enabled for your account. You can disable 2FA on the settings page. For more in-depth details on two-factor authentication, see the reference page.

How to use the API?

Faction AA

Faction AA refers to the Faction API Access permission in-game. Members with faction positions granting this permission will have read-only access to faction data through the Torn API.

WARNING: Members granted the AA permission will be able to access data through the API even if they don’t have the permissions to access the data in-game. For example, a member with the AA permission who doesn’t have banking permissions will not be able to see other members’ vault balances in-game but can view them through the API.

Tornium utilizes the AA permission to grant faction members permission/access to modify certain faction-related features that aren’t attached to Discord servers. Additionally, Tornium uses the API keys of members with the AA permission to retrieve faction data for features such as banking, retaliations, and others. As such, it is heavily discouraged to grant every member the AA permission.

A faction leader/co-leader can grant and revoke faction positions on the faction positions page under Faction > Controls > Positions. On the faction permissions page, the leader/co-leader will be able to change permissions for each position by pressing the cross or check marks to respectively enable or disable the selected permission for the specified faction position.

Notifications

Notifications are installed and configured notification triggers. A notification will send the message set up in the notification trigger when the trigger is activated according to its Lua code. For more information on how notification triggers work, view the notification trigger reference.

WARNING: As stated in Tornium’s Terms of Service, you are not allowed to use this feature to disrupt Tornium. Intentionally malicious use of this feature is not permitted and may result in a banning of the user, user’s faction, and/or user’s Discord server.

Notification Configuration

TODO

Bot Notification Configuration

TODO

Notification Triggers

Notification triggers (aka triggers) provide the underlying logic for notifications through Lua code and Liquid templates.

At this time, only official notification triggers can be used. Once notifications and the underlying architecture is stable, the creation of custom notification triggers will be enabled.

WARNING: As stated in Tornium’s Terms of Service, you are not allowed to use this feature to disrupt Tornium. Intentionally malicious use of this feature is not permitted and may result in a banning of the user, user’s faction, and/or user’s Discord server.

Trigger Metadata

TODO

Trigger Conditions

TODO

Trigger Template

TODO

API Calls

TODO

Bot Verification

Tornium’s Discord member verification updates a Discord member’s roles and nickname according to the server’s verification configuration and the member’s Discord ID. If a Discord member is not verified, all configured roles will be removed from them unless they have an exclusion role and the member will be given the unverified roles. The verification feature requires a Discord server’s member to be verified through the official Torn Discord server to determine which Torn user corresponds to a Discord user.

NOTE: Due to restrictions with Discord’s permission system, Tornium is unable to modify the nicknames and roles of server members with a role higher than the bot’s highest role or modify the server owner. Changes to these members need to be done manually by a server administrator. Server owners are considered to be the highest role in the server by Discord, so the bot will never be able to verify the server owner.

Verification Configuration

To customize your server’s verification process, Tornium has several options that can be configured:

These configuration options can be set on the Tornium website on the verification dashboard for any Discord server the Tornium bot is in. For basic information on setting up verification in a Discord server, the tutorial is recommended.

Global Toggle

The verification global toggle enables or disables all verification methods for that Discord server. The global toggle does not delete any saved configurations which allows verification to be later enabled without any further configuration.

Log Channel

All verification log messages will be sent to the specified verification log channel or thread in the Discord server. Currently, only successful/failed changes to members during /verifyall and the verification cron will be logged to this channel.

Jail Channel

All un-verified members who have joined the server are intended to arrive through this channel or thread. If the Discord server has verification-on-join enabled, the bot will send messages regarding successful/unsuccessful verification in the jail channel. If the member is not verified through Torn, the bot will indicate methods for the member to verify themselves.

Verification Cron Toggle

The verification cron toggle will enable/disable automated daily verification of all members in the Discord server. For more information, see verification-cron.

Verification-on-Join Toggle

The verification-on-join toggle will enable/disable verification of new members when they join the Discord server. For more information, see verification-on-join.

Name Template

The verification name template is used to generate the nickname for all members in the Discord server. By default, the template is {{ name }} [{{ tid }}] such that the nickname of Chedburn would be Chedburn [1]. However, this can be customized with the name template at runtime using the Liquid templating language and the following variables:

VariableDescriptionExample
{{ name }}Torn usernameChedburn
{{ tid }}Torn user ID1
{{ tag }}Torn user’s faction tagCR

If the user is not in a faction, the faction tag will fallback to an empty string "".

Verified Roles

Members of the Discord server will be given these roles if they are verified by Torn.

Unverified Roles

Members of the Discord server will be given these roles if they are NOT verified by Torn.

Exclusion Roles

All members in the Discord server who have an exclusion role will not be verified through any verification method. These members will have to have their nickname and roles be manually updated by a server administrator. Exclusion roles are commonly used to allow faction members who are guesting to retain faction-related roles and to skip verification of server administrators.

TIP: It is suggested to give faction leadership and guesting members these roles. Faction leaders and co-leaders are not assigned faction positions by the bot and members who are guesting will have their faction-related roles removed from this. Giving these members an exclusion role will allow them to retain their roles and their roles will have to be changed manually.

Faction Roles

Members of the Discord server can be given role(s) corresponding to their faction in-game. If the member is not in a faction configured for verification in the Discord server, there will be no faction-related changes during verification. The factions configured for faction roles during verification do not have to be linked to the Discord server.

Faction Position Roles

Members of the Discord server can be given role(s) corresponding to their faction positions for their faction in-game. Assigning roles to faction positions requires adding the faction to the list of factions the Discord server will verify, but faction roles are not required to set up this feature.

This feature requires configured factions to maintain a link between the configured faction and the Discord server. Additionally, to avoid leaking potentially sensitive data, only members of that faction with the faction’s AA permission will be able to configure this feature.

Verification Methods

To perform the verification of Discord server members, Tornium supports three options:

  • Verification-on-join: New members of the Discord server will be verified upon joining the server
  • Verification cron: All members of the Discord server will be verified daily
  • Slash commands: Members of the Discord server can be verified through a series of slash commands

Verification-on-Join

Verification-on-join utilizes the Discord gateway to verify new members of the Discord server as they join. Upon detecting the member joining the Discord server, the bot will attempt to verify the member according to the Discord server’s verification configuration. If the verification configuration has verification-on-join disabled, no verification (including API calls) will be performed.

Once verification is complete, if a jail channel is configured, the bot will send a message regarding the success of verification to the jail channel. It is assumed that the jail channel is where new members land as the bot’s message includes instructions on how the member can verify for members who are not already verified.

Verification Cron

The verification cron will attempt to verify all members of the Discord server if enabled through the cron toggle. The verification cron occurs at a time calculated from the Discord server’s ID which can be found on the verification dashboard under Automatic Verification. At that time, the cron will start to verify all members of the Discord server. This process can take several minutes depending on load on Tornium’s servers, the number of members of the Discord server, and the number of API keys to be used. As the verification process progresses, messages regarding the success of verification for individual members will be sent to the configured log channel.

NOTE: Larger Discord servers will need to have multiple API keys to process verification in a timely manner. The Torn API ratelimits API calls per key owner and, to avoid using all of a user’s ratelimit, Tornium only utilizes a portion of that ratelimit.

Slash Commands

Tornium’s Discord bot contains two slash commands related to performing verification:

  • /verify: Command to verify yourself or another member
  • /verifyall: Command to manually start verification cron

Verify Command

/verify [member]

The /verify slash command will attempt to verify a member of the Discord server according to the Discord server’s verification configuration.

ArgumentDescriptionRequiredDefault
memberDiscord server member to be verifiedFalseInvoker of the command

Verify All Command

/verifyall

The /verifyall slash command will manually start the verification cron to verify all members of the Discord server in the background. This verification process can take up to several minutes. For more information, see the verification cron.

Verify User Command

The verify user command will silently attempt to verify the member of the Discord server selected according to the Discord server’s verification configuration.

There are no arguments for user commands.

Bot Organized Crimes

Tornium supports notifications for organized crime-related events:

Tornium updates and performs all checks for the latest organized crimes every five minutes. All features can be configured to send messages in specific channels and ping roles. Additionally, all features can be optionally configured to only check against specific OC names (e.g. Honey Trap).

WARNING: This series of features is in active development and will change as time passes. DEPRECATION NOTICE: Factions remaining on OCs 1.0 are deprecated and will no longer be supported on August 1st.

These configuration options can be set on the Tornium website on the organized crimes dashboard for any Discord server the Tornium bot is in. For basic information on setting up OCs in a Discord server, the tutorial is recommended.

Missing Tools OCs

When configured, Tornium will alert when an organized crime has a member missing a required tool or material. This will only be alerted upon 24 hours before an organized crime would be ready.

Delayed OCs

When configured, Tornium will alert when an organized crime has been delayed by a member not being available (e.g. in the hospital or flying) when the organized crime is ready.

Extra Range OCs

When configured, Tornium will alert when an organized crime has a member whose CPR is outside the configured bounds for that organized crime. The global minimum-maximum will be used when a per-OC minimum-maximum pair is not set.

  • Global Minimum: The default minimum CPR for all OCs
  • Global Maximum: The default maximum CPR for all OCs
  • Per-OC Minimum: The minimum CPR for all OCs with that name
  • Per-OC Maximum: The maximum CPR for all OCs with that name

Banking

Tornium’s banking allows faction members to request money and faction bankers to fulfill/cancel vault requests. Once a vault request is marked as fulfilled, the banker needs to be fulfilled within ten minutes; without a vault log indicating the vault request has been fulfilled, the bot will mark the vault request as not fulfilled and cancel it. By default, if a vault request is not fulfilled within ~60 minutes, the bot will automatically cancel the request in an attempt to prevent the requester of the vault request from being mugged after going offline. This can be configured by the member making the request though.

Banking Configuration

Under the Faction Banking section of the faction’s linked Discord server, the faction’s banking channel and optional role(s) can be configured. The banking channel is the location vault requests will be sent to. If the optional banking role(s) are configured, the roles will be mentioned in the request sent to the banking channel.

Slash Commands

Tornium’s Discord bot contains four banking-related slash commands:

  • /balance: Command to check a member’s balance
  • /withdraw: Command to perform a vault request
  • /cancel: Command to cancel a vault request
  • /fulfill: Command to fulfill a vault request

Balance Command

/balance [member]

The /balance slash command will attempt to retrieve the user’s faction vault balance for their current faction. This command requires a member of their faction with AA permissions to be signed in Tornium.

If this slash command is invoked in a Discord server and the invoker of the command has AA permissions in their faction, a Discord user can be included to retrieve that other user’s vault balance if both users are in the same faction.

ArgumentDescriptionRequiredDefault
memberDiscord server member to retrieve balance ofFalseInvoker of the command

Withdraw Command

/withdraw (amount) [option]

The /withdraw slash command will send a vault request for the specified amount of money or points to the banking channel mentioning the banking role as configured for the faction of the invoker. Before sending the vault request to the banking channel, the bot will verify the member has a sufficient balance of money or points in the faction vault. Additionally, the member can not have pending requests of which the balance would go over the member’s balance with the request being made.

ArgumentDescriptionRequiredDefault
amountAmount of money/points to be withdrawnTrueNone
optionFlag to request money or points to be withdrawnFalseMoney
timeoutAmount of time before the request will time outFalse1 hour

The (amount) parameter allows for the suffixes used by Torn for ease-of-use as shown below (e.g. 4.3m represents 4,300,000). Additionally, all can be used in place of a numeric amount to request all of the member’s vault balance.

SuffixAmount
1K1,000
1M1,000,000
1B1,000,000,000

Cancel Command

/cancel [id]

The /cancel slash command will cancel a vault request. If no vault request ID is provided, the most recent vault request by the user will be cancelled. If a vault request ID is provided and the user has AA permissions, the specified vault request will be cancelled.

ArgumentDescriptionRequiredDefault
idVault request ID to be cancelledFalseMost recent vault request

Fulfill Command

/fulfill (id)

The /fulfill slash command will mark a vault request as fulfilled by the command invoker.

ArgumentDescriptionRequiredDefault
idVault request ID to be fulfilledTrueNone

Website

In addition to the above slash commands, faction members can make vault requests and view previous vault requests through the Tornium website. At the top of this page, members can input the amount (of only money) to withdraw and submit the request; this process works the same as the /withdraw slash command. Below this, members can view a list of faction bankers and a list of their previous vault requests.

Overdose

Tornium’s overdose notifications allow factions to have messages sent to Discord when faction members overdose.

Overdose Configuration

Under the Faction Overdose section of the faction’s linked Discord server, the faction’s overdose channel and overdose policy can be configured. The overdose channel is the location overdose notifications will be sent to. The overdose policy controls how notification will be sent to the overdose channel. If the overdose policy is set to daily, all overdoses not previously notified up to 24 hours earlier will be sent in one message. If the overdose policy is set to immediate, overdoses notifications will be sent as the overdose is first registered to the database.

Chain List Generator

The chain list generator pulls users from Tornium’s stat database and filters the users to determine which users may be good chain targets providing good respect. The configuration users provide help limit the generated targets to those that will be useful to the user.

Configuration Options

The chain list generator supports the following configurations:

  • Difficulty Range: The range in fair fight the targets should provide.
  • Level Range: The range in levels the targets should be within.
  • Sort Order: The order the database will list the targets in.
  • Limit: The maximum number of targets that will be returned.
  • Inactive Only: Only targets that should be inactive for more than 30 days.
  • Factionless Only: Only targets that should not be in a faction.

The difficulty range, level, and limit configuration options support custom values. Adding a custom value can be done by removing the existing value from the input, typing out a new value, and pressing “Add”. See the sections for each configuration option for more information on how this works for each configuration option.

NOTE: If the Inactive Only and/or Factionless Only filters are used, then an additional filter is utilized to prevent stale data from being included. Depending on the difference between the target’s last activity in Tornium’s database and last update to Tornium’s database, there will be a maximum staleness of the data of between 27 and 90 days.

Difficulty Range

The difficulty range is the range of fair fight targets will be generated for.

Level Range

The level range is the range of targets’ level for which targets will be generated for. The level must be between 1 and 100.

Sort Order

The order targets are sorted by the database when generated.

  • Recently Updated: Targets will be sorted by the most recently updated stat data for targets.
  • Highest Respect: Targets will be sorted by the highest respect if they were to be attacked. This is based on the user’s most recent stat score and the target’s most recent stat score and level.
  • Random: Targets will be sorted randomly.

Limit

The maximum number of targets when the chain list is generated. The limit must be between 1 and 250.

Inactive Only

The generated list of chain targets will only contain targets who should be inactive. The targets will be last active more than 30 days ago according to the database and the targets will have been updated less than 21 days ago. This ensures the target’s last action timestamp has been updated sufficiently recently.

Factionless Only

The generated list of chain targets will only contain targets who should not be in a faction.

OAuth Provider

Tornium includes an OAuth provider following RFC 6749 to allow users to securely interact with Tornium’s API. This document outlines supported flows, client registration, and general security considerations.

Supported Flows

Tornium supports the following OAuth flows:

Authorization Code Grant

Authorization code grant is the typical OAuth2 flow with an authorization code exchanged for the user’s access token. This reference will NOT describe all the intricacies of OAuth2; it is suggested that you read all related RFCs.

For OAuth requests, a private client MUST use the client_secret_basic client authentication method in a POST request with the following format:

Authorization: Basic {{ Base64(<client_id>:<client_secret>) }}

Additionally, a public client MUST use the none client authentication method and MUST use Proof Key for Code Exchange (PKCE).

Client Authorization

The client MUST redirect the user to Tornium’s authorization URL to authorize the application for their user for the requested scopes. Upon acceptance by the user, Tornium will redirect the user to the client through the included redirect_uri. The authorization code will be provided as the query parameter code. The authorization redirect URI to Tornium MUST be of form:

https://tornium.com/oauth/authorize?response_type=code&client_id={{ client_id }}&state={{ state }}&scope={{ scope }}&code_challenge_method=S256&code_challenge={{ code_challenge }}&redirect_uri={{ redirect_uri }}

Redirect URI

Upon successful authorization by the user and redirection to the redirect_uri, the code as a query parameter in the redirect MUST be exchanged for the user’s access token with a POST request to the token URL:

POST /oauth/token HTTP/1.1
Host: tornium.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic {{ base64_client_secret }}

code={{ code }}&grant_type=authorization_code&scope={{ scope }}&client_id={{ client_id }}&code_verifier={{ code_verifier }}&redirect_uri={{ redirect_uri }}

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
    "access_token": "{{ access_token }}",
    "token_type": "Bearer",
    "expires_in": {{ expires_in }},
    "refresh_token": "{{ refresh_token }}"
}

Refresh Token Grant

To avoid indefinite impersonation of users on a public client (which are unable to properly secure a refresh token), only confidential clients may utilize the refresh token grant. The refresh token grant will revoke the user’s current access token for the client and grant a new access token with an updated expiration.

POST /oauth/token HTTP/1.1
Host: tornium.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic {{ base64_client_secret }}

grant_type=refresh_token&refresh_token={{ refresh_token }}

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
    "access_token": "{{ access_token }}",
    "token_type": "Bearer",
    "expires_in": {{ expires_in }},
    "refresh_token": "{{ refresh_token }}"
}

Client Registration

For an application to interact with Tornium’s API, the application MUST be registered with the following information:

  • Redirect URIs: List of whitelisted URLs for authorization code grant that MUST NOT contain wildcards.
  • Scopes: List of scopes limiting data access of the application.
  • Client URI: URI of the homepage or main page of the application.
  • Client ToS URI: URI of the terms of service of the application.
  • Client Privacy Policy URI: URI of the privacy policy of the application.

The linked privacy policy MUST list/explain the following:

  • The data retrieved from Tornium
  • The usage of that data
  • Retention of that data
  • How that data can be deleted
  • How and why that data is shared

The linked privacy policy SHOULD also include the following:

  • A method to contact the application’s developer regarding data concerns
  • A description of how user data is protected by the application

NOTE: Tornium currently does not support Dynamic Client Registration (RFC 7591), so clients can only be registered through Tornium.

Scopes

This is a list of Tornium’s OAuth2 scopes required for use of certain endpoints in the Tornium API. The documentation for individual API endpoints will state which scopes, if any, are required. By default, an application has access no scopes.

NameDescription
identityallows access to information on a user’s identity
factionallows access to all information on the user’s faction
faction:attacksallows access to information related to the attacks of a user’s faction
faction:bankingallows access to the Tornium banking of a user’s faction
faction:crimesallows access to the organized crime information of the user’s faction
torn_key:usageallows the usage of the user’s API key

Security Considerations

  • To help prevent cross-site request forgery and clickjacking, the state parameter (RFC 6749) is REQUIRED for all clients. The state parameter will bind the user’s authorization request to their authenticated state and MUST be sent in the authorization request and will be returned in the response. The client MUST validate the redirection by matching the redirected state; a mismatched state parameter may be the result of an intercepted request or failed authorization and its request MUST be denied.
  • PKCE (RFC 7636) is REQUIRED for all public clients and is RECOMMENDED for all clients.
  • All redirect URIs MUST use HTTPS.

For more information, it is RECOMMENDED to read the relevant OAuth2 RFCs.

Endpoints

The Tornium API supports the following resource APIs:

All API endpoints require OAuth authentication and authorization against a registered application before performing any API calls.

All API endpoints share a 250 per minute global ratelimit, however this ratelimit can change without notice. Therefore, clients SHOULD rely upon ratelimiting headers to determine calls remaining and the ratelimit expiration. The ratelimiting will use the following headers:

  • X-RateLimit-Limit: Maximum number of API calls until the ratelimit expires
  • X-RateLimit-Remaining: Number of API calls remaining until the ratelimit expires
  • X-RateLimit-Reset: Seconds until the ratelimit expires

WARNING: API endpoints are subject to change, potentially without notice.

API Errors

All API errors will be of the format:

{
    "code": <integer>,
    "name": <string>,
    "message": <string>,
    "details?": <object>
}

If more information is available beyond the base API error, the details field will be populated (typically under details.message). A list of valid API errors can be found in the source code.

Faction API

Get Faction Retaliations

Get all known, potential retaliations for the user’s faction.

Scopes Required: faction:attacks (or faction)

GET /api/v1/faction/<int:faction_id>/attacks/retaliations HTTP/1.1
Authorization: Bearer {{ access_token }}

[
    {
        "code": "bd80bb9c505a97ce7d66ddeee9433cf0",
        "attack_ended": 1761708665,
        "defender: {
            "ID": 2383326,
            "name": "tiksan"
        },
        "attacker": {
            "ID": 1,
            "name": "Chedburn"
        }
    }
]

Get Faction Member Balance

Get the balance of the authenticated user in the vault of the user’s faction.

Scopes Required: faction:banking (or faction) and torn_key:usage

GET /api/v1/faction/banking/vault HTTP/1.1
Authorization: Bearer {{ access_token }}

{
    "player_id": 2383326,
    "faction_id": 15644,
    "money_balance": 123456,
    "points_balance": 123
}

Create Faction Vault Request

Create a vault request against the authenticated user’s faction. This requires the faction to be linked to a Discord server and to have banking set up on that Discord server.

The amount parameter supports the same values as the slash command including values such as "all", "1m", and 1000000. If the timeout parameter is null, the request will never time out.

The guid in the vault request response can be used to create a fulfillment link of the form:

https://tornium.com/faction/banking/fulfill/<guid>

Scopes Required: faction:banking (or faction)

POST /api/v1/faction/<int:faction_id>/banking HTTP/1.1
Authorization: Bearer {{ access_token }}
Content-Type: application/json

{
    "amount": "all",
    "type": "money_balance",
    "timeout": 1761708665
}

{
    "id": 1234,
    "guid": "dc79b83b-2ece-4ce9-9324-59464e89baaa",
    "user_id": 2383326,
    "faction_id": 15644,
    "amount": 12345678,
    "type": "money_balance",
    "expires_at": 1761708665
}

Body Parameters

FieldTypeDescriptionDefaultRequired
amountInteger or StringAmount to withdrawTrue
typeStringType of request: money_balance or points_balanceTrue
timeoutUnix Timestamp or nullEarliest expiration timestampNeverFalse

Cancel Faction Vault Request

Cancel a vault request against the authenticated user’s faction. If the user has banking permissions, the user can cancel any faction members’ vault request. If the use does not have banking permissions, they can only cancel their own vault requests.

The request_id path parameter can either be the wid of the request or the guid of the request. This API endpoint return HTTP 204 with no response body if the request has been successfully cancelled.

Scopes Required: faction:banking (or faction)

DELETE /api/v1/faction/<int:faction_id>/banking/<request_id> HTTP/1.1
Authorization: Bearer {{ access_token }}

List Vault Requests

List all applicable vault requests against the authenticated user’s faction.

If the search_type is pending, this endpoint will return all requests that have not been fulfilled or cancelled; otherwise, the endpoint will return all requests. If the scope is faction and the user has banking permisions, this endpoint will return either the pending or all requests for all faction members; otherwise, if the scope is user, the endpoint will return the pending or all requests for the authenticated user.

Scopes Required: faction:banking (or faction)

GET /api/v1/faction/<int:faction_id>/banking HTTP/1.1
Authorization: Bearer {{ access_token }}

Query Parameters

FieldTypeDescriptionDefaultRequired
search_typeStringType of request: pending or allpendingFalse
scopeStringScope of requests: user or factionuserFalse
limitIntegerResponse limit (1-100)100False
beforeUNIX timestampLatest timestamp to returnFalse

Get Organized Crimes Names

Get a list of names of all organized crimes. The data from this API endpoint is cached for an hour.

GET /api/v1/faction/crime/names HTTP/1.1
Authorization: Bearer {{ access_token }}

[
    "Break the Bank",
    "Market Forces",
    "Clinical Precision"
]

Get Organized Crime Delays

Get a list of members of the authenticated user’s faction who have delayed organized crimes.

Scopes Required: faction:crimes (or faction)

GET /api/v1/faction/<int:faction_id>/crime/delays HTTP/1.1
Authorization: Bearer {{ access_token }}
Content-Type: application/json

{
    "limit": 50
}

[
    {
        "oc_id": 1234,
        "user_id": 2383326,
        "oc_position": "Muscle",
        "oc_position_index": 3,
        "delay_reason": "Flying to Mexico"
    }
]

Query String Parameters

FieldTypeDescriptionDefaultRequired
beforeIntegerMinimum OC ID for paginationFalse
afterIntegerMaximum OC ID for paginationFalse
limitIntegerMaximum number of delays100False

Get Faction Members

Get a list of members of a specific faction.

Scopes Required: none

GET /api/v1/<int:faction_id>/members HTTP/1.1
Authorization: Bearer {{ access_token }}

[
    {
        "ID": 2383326,
        "name": "tiksan",
        "level": 100,
        "discord_id": 695828257949352028
    }
]

[DEPRECATED] Get Faction Positions

Get a mapping of faction positions for the authenticated user’s faction.

Scopes Required: faction

GET /api/v1/faction/positions HTTP/1.1
Authorization: Bearer {{ access_token }}

{
    "positions": [
        {
            "_id": "2da1bfe9-d654-43a2-9733-ef76bfb6e500",
            "name": "Crusader",
            "faction_tid": 15644,
            "default": True,
            "use_medical_item: False,
            "use_booster_item: False,
            "use_drug_item: False,
            "use_energy_refill: False,
            "use_nerve_refill: False,
            "loan_temporary_item: False,
            "loan_weapon_armory: False,
            "retrieve_loaned_armory: False,
            "plan_init_oc: False,
            "access_fac_api: False,
            "give_item: False,
            "give_money: False,
            "give_points: False,
            "manage_forums: False,
            "manage_applications: False,
            "kick_members: False,
            "adjust_balances: False,
            "manage_wars: False,
            "manage_upgrades: False,
            "send_newsletters: False,
            "change_announcement: False,
            "change_description: False
        }
    ]
}

Stat API

Generate Chain List

Generate a chain list for the authenticated user. The authenticated user must have a stat score in the database, either from being logged into Tornium with an API key or through the faction’s TornStats.

This API endpoint has an additional ratelimit currently set to 5 per minute.

Scopes Required: none

POST /api/v1/stat/chain-list HTTP/1.1
Authorization: Bearer {{ access_token }}
Content-Type: application/json

{
    "minimum_difficulty": 1,
    "maximum_difficulty": 3,
    "minimum_level": 1,
    "maximum_level": 100,
    "sort_order": "respect",
    "limit": 100,
    "is_factionless": True,
    "is_inactive": True
}

[
    {
        "time_added": 1761708665,
        "stat_score": 1234,
        "fair_fight": 1.23,
        "respect": 2.19,
        "target": {
            "ID": 2383326,
            "name": "tiksan",
            "faction": {
                "ID": 15644,
                "name": "New Sith Order"
            },
            "last_action": 1761708665,
            "last_refresh": 1761708665
        }
    }
]

JSON Parameters

FieldTypeDescriptionDefaultRequired
minimum_difficultyNumberMinimum fair fight the target would provide1False
maximum_difficultyNumberMaximum fair fight the target would provide3False
minimum_levelIntegerMinimum level the target has1False
maximum_levelIntegerMaximum level the target has100False
sort_orderStringSort order of the targets (random, recently-updated, highest-respect)randomFalse
limitIntegerMaximum number of targets to list25False
is_factionlessBooleanFlag to only include targets that are not in factionsFalseFalse
is_inactiveBooleanFlag to only include targets that are not activeFalseFalse

Stocks API

Get Stocks Data

Get the data on all stocks for the last known tick. Returns a map of stock IDs and stock data.

Scopes Required: none

GET /api/v1/stocks HTTP/1.1
Authorization: Bearer {{ access_token }}

{
    "1": {
        "timestamp": 1761708665,
        "price": 787.59,
        "market_cap": 14250000000,
        "shares": 12374372,
        "investors": 134,
        "acronym": "MCS"
    }
}

Get Stock Benefits Data

Get the list of benefits for each stock.

Scopes Required: none

Get stock Movers Data

Get the lists of gainers and losers over the periods:

  • d1 (24 hours)
  • d7 (7 days)
  • m1 (30 days)

Scopes Required: none

Users API

Get User

Get the information on the authenticated user.

Scopes Required: identity

GET /api/v1/user HTTP/1.1
Authorization: Bearer {{ access_token }}

{
    "tid": 2383326,
    "name": "tiksan",
    "username": "tiksan [2383326]",
    "last_refresh": 1761708665,
    "discord_id": 695828257949352028,
    "factiontid": 15644,
    "last_action": 1761708665
}

Get Specific User

Get the information on specific Torn user.

Scopes Required: none

If the target user is to be updated, the torn_key:usage scope must be included.

GET /api/v1/user/<int:user_id> HTTP/1.1
Authorization: Bearer {{ access_token }}

{
    "tid": 2383326,
    "name": "tiksan"
    "username": "tiksan [2383326]",
    "level": 100,
    "last_refresh": 1761708665,
    "discord_id": 695828257949352028,
    "faction": {
        "tid": 15644,
        "name": "New Sith Order"
    },
    "last_action": 1761708665
}

Query String Parameters

FieldTypeDescriptionDefaultRequired
refreshBooleanIf the target user’s data should be refreshedFalseFalse

Get User Stats Estimate

Get the stat estimate of a specific user through Tornium’s stat estimation model.

Scopes Required: none

If the user has an API key and the torn_key:usage scope is included, the target user’s data may be updated if the target user’s personal stats were last updated more than a one week previously.

GET /api/v1/user/estimate/<int:user_id> HTTP/1.1
Authorization: Bearer {{ access_token }}

{
    "stat_score": 1234,
    "min_bs": 380689,
    "max_bs": 553729,
    "expiration": 1761708665
}

Get User Historical Stats

Get the latest historical stats of a specific user through Tornium’s stat database.

Scopes Required: None

GET /api/v1/user/<int:user_id>/stat HTTP/1.1
Authorization: Bearer {{ access_token }}

{
    "stat_score": 1234,
    "min": 380689,
    "max": 553729,
    "timestamp": 1761708665
}

Two-Factor Authentication

Two-factor authentication (2FA) provides an additional layer of security on top of the primary form of logging into Tornium (an API key or through Discord). This ensures that a user’s Tornium account remains secure even if their API key(s) or Discord account are compromised. Once enabled, users will be required to sign in with an API key or through Discord then enter a code generated by an authenticator app.

Supported 2FA Methods

  • TOTP (Authenticator App): App that generates a six-digit token every 30 seconds.
  • Backup Codes: List of one-time use backup codes for when the authenticator app is unavailable.

Enable 2FA

2FA can be enabled through the Tornium settings page under the “Two-Factor Authentication” section. While setting up the authenticator app, you can scan the QR code or manually enter the secret into the authenticator app, but neither are accessible after this. Once the authenticator app has been set up for Tornium, you will need to enter the code generated by the app to verify that 2FA has been setup properly. If it has been setup properly, 2FA will be immediately enabled.

Once 2FA is enabled, it is suggested to download backup codes associated with your user. These one-time use codes will allow you to go through 2FA even if you are unable to access the authenticator app. Once downloaded, these codes can not be accessed without regenerating the codes and invalidating the previous codes.

Disable 2FA

2FA can be enabled through the Tornium settings page under the “Two-Factor Authentication” section. Once 2FA is disabled, the previous secret and all remaining backup codes will be deleted and can not be reused.

Recovery

If you are unable to access your Tornium account due to 2FA and don’t have access to your backup codes, contact tiksan [2383326] on Torn only through a mail or chats. Discord messages regarding 2FA will be ignored to due a vulnerability in Torn’s Discord linking feature.

Tornium Estimate

The Tornium estimate userscript shows users’ stats in-game according to the historical stat database or statistically-modeled stat estimations. For information on installing the userscript, see the tutorial.

NOTE: For features that only show fair fight due to space limitations, the userscript will prefer using the stat DB unless the data from the stat DB is over a month old. If the data is too old, the userscript will use a stat estimation instead.

How does it work?

Depending on the page, the userscript will make an API call to Tornium’s servers to retrieve an estimate of the user’s stats or to retrieve the users stats from its database. An uncapped fair fight score will also be generated from your stats the last time you’ve visited the gym page. Being uncapped, this allows you to quickly see the relative strength of the target with 3x FF being about 50-75% of your stats.

Support Pages

Currently, the userscript supports the following in-game pages:

Profile

On both your and other users’ profiles, the userscript will show both the last accessible stat for the user according the stat DB and the user’s stat estimate. Additionally, here you can access userscript’s settings by pressing the Estimate Settings button.

Faction RW

On both your faction’s RW page and other faction’s RW pages, the userscript will show the fair fight the target should give you in the column the target’s level is normally in.

For in-game donators/subscribers, you can use the advanced search to filter and search through users. The userscript will show the fair fight the target should give you next to the target’s name.

NOTE: It is suggested to disable Honor Names in Torn’s settings as the fair fight may be unreadable on certain honor bars.

Attack Loader

On attack loaders, Tornium will show the user’s stats from the stat DB or stat estimate underneath the Start Fight button.

Abroad People

When abroad in a different country, Tornium will show the fair fights of the users next to the targets’ icons.