DATA POLICIES

The topics discussed below represent Riot’s policies as they stand right now. Our policies evolve and change as the community and our understanding of it grows. This page will be updated whenever any policies relevant to the API change. Violating any of the policies below can result in revocation of your access to the public API.

RANKED VS. UNRANKED GAMES

We no longer have any policies dictating that ranked and unranked games should be treated any differently by third party developers.

CUSTOM LADDERS OR CHALLENGES

Custom ladders and challenges have become common for unranked games, but have the potential to warp gameplay. Projects should not host ladders or ranking systems that may alter or detract from the objective of the game. Custom ladders or ranking systems may be created as long as they aren’t replacements for official Riot systems. If aspects of a project alter gameplay or act as a replacement for an official system we may ask that the system, or project, be discontinued.

Projects should never suggest custom challenges or contests to be carried out in a matchmade game unless they are communicated and accepted by all members of the participating team. Destroying the Nexus should always remain the primary intent of the game. A challenge or contest whose goal is anything other than achieving a victory is strictly forbidden. If a custom challenge or contest leads to dissatisfaction, frustration, or anger amongst teammates we may ask that the challenge, contest, system, or project be discontinued.

As always, if you think your project contains an edge case and you’re not sure if it will come into conflict with our policies, please reach out to us via the messages within your application.

AGGREGATED STATISTICS

Feel free to dissect players’ ranked and unranked match history to provide the community with detailed insights. Developers may display aggregated statistics to provide win rates, KDA, or other measures of their performance, however queues used to aggregate these stats must be clearly identified. For example, if you wanted to display a player’s Fiora stats you’d need to identify which queues you used to determine their win rate, KDA, etc. If you’re showing stats for a player’s recent games, you must indicate the stats were generated from every queue. The priority here is providing a clear context for a player’s stats.

Clearly identifying queues used to aggregate stats also applies when comparing aggregated stats between players. We never allow shaming based on a player’s performance which is reflected in our General Policies. You may choose to honor or glorify a player based on their performance, but we don’t allow for projects to make assumptions that could lead to negative preconceptions about a player (i.e., tilted, toxic, feeder, etc.).

As always, if you think your project contains an edge case and you’re not sure if it will come into conflict with our policies, please reach out to us via the messages within your application.