It's been a common topic around the Riot Games API Community that CORS has prevented client side calls to the API.

There is a guide that Tux made for v3 APIs with AWS Lambda functions, but what if we wanted something more up to date and flexible that we don't need to constantly update?

I've made a script to use any endpoint and help cache responses to help alleviate rate limiting concerns, although if you're requesting a lot of matches through the function you could still run into issues on rate limits.

Caching data on Lambda is more complex/pricey, but this script could be modified to be used on Lambda as well, I just prefer it less.

The downside of using these functions is that anybody can technically use your endpoints and use your function calls/Riot API Limits, if this is a concern I'd recommend you create a back-end to your app. This could be in anything like Node.js, Python, Golang, Java, or whatever today's flavor of the day is.

Getting Started

With that data out of the way, let's get started.

You will need a Cloudflare account. You can sign up for one at https://dash.cloudflare.com/sign-up

For this example we will be using the Free plan of Cloudflare Workers, you can make up to 100,000 requests per day, if you need above that amount you should probably consider a backend.

To get started go to https://workers.cloudflare.com/

Sign up if you haven't already, choose a domain name that matches your project, then choose the plan that fits you.

Once done create a service, name it something that makes sense. For this we are using the name example, keep Introduction chosen we are going to replace the code anyways.

Once you got your service up and going, choose Quick Edit.

We are going to use code from a gist I've made so that there is minimal effort in the coding needed.

Using Cloudflare Workers to Make Requests to Riot Games API

Using Cloudflare Workers to Make Requests to Riot Games API - example.js

Gist262588213843476

Go ahead and copy and paste the code into your worker, replacing any code it originally gave you in its example.

We will need to change our constants at the top of the script to match our needs.

API_KEY: Your Riot Games API key, this can be a developer, personal, or production key.

API_ENDPOINT: Unless you have a reason you don't need to change this

CACHE_TIME: This by default is 10 minutes, this means once you make an API call it won't make the same call for 10 minutes, if you're trying to do something like fetch a current match or the latest match you may want to lower this.

ALLOWED_ORIGINS: Change this to your domain name, if you're using www include www, if not don't. If you're using both include both. Use a * if you'd like to allow all domains but this will allow anybody to use your workers.

Once you have those all set you're ready to make an API call through, go ahead Save and Deploy!

Examples

Example 1: Path Parameters

The endpoint parameter will be exactly as it shows on the Riot Game Developer portal, in our example we are using the Summoner-V4 endpoint by-name.

This endpoint is /lol/summoner/v4/summoners/by-name/{summonerName}.

Since this is a v4 league endpoint we will use a platform region of na1.

The way this script is setup is any path parameters like summonerName here we will append as an additional GET parameter. You also can replace it in the endpoint as well if it makes more sense for you.

So for this request we will use:

https://example.bangingheads.workers.dev/api/?region=na1&endpoint=/lol/summoner/v4/summoners/by-name/{summonerName}&summonerName=Headbang

Now obviously you will need to change this to your domain name to test it.

We should get our response of the Summoner-V4 JSON.

Example 2: Additional GET Parameters

This also works for endpoints that have additional get parameters that we can add to the end of the URL.

For example Match-V5 has a count parameter, we are setting count to 100 here.

Our endpoint is /lol/match/v5/matches/by-puuid/{puuid}/ids

Our region is americas

Our example puuid is f83au5bQ3XCRxvP3_xAEcki5wnHZ22ZhSkbp5wRpg0j5W-pJnPL_C1q3QVdWBV9xF8g_5ADYduuEZg

This builds our URL into:

https://example.bangingheads.workers.dev/api/?region=americas&endpoint=/lol/match/v5/matches/by-puuid/{puuid}/ids&puuid=f83au5bQ3XCRxvP3_xAEcki5wnHZ22ZhSkbp5wRpg0j5W-pJnPL_C1q3QVdWBV9xF8g_5ADYduuEZg&count=100

Now that you understand the basics, feel free to make any modifications to the script as you find are needed, or feel free to ping me in the Riot API/Hextech Docs discord @BangingHeads with any questions.

In this Example I'm going to be using my C# Lib PoniLCU.

First of all let's set our LeagueClient properly.

LeagueClient leagueClient = new LeagueClient(credentials.cmd);

Before we dive into it, let's look at what runes are.

The client doesn't deal with the runes as the same as you do.
The client doesn't know what DarkHarvest is, it only knows of it by its id. Which in this case is 8128.

But, how did I know that? You can find a JSON of all runes data here.

To push runes to the client, you need to use the lol-perks plugin which you can find info about here.

How do we actually start pushing runes?

Unfortunately you can't just request PUT lol-perks/v1/currentpage you've seen at the website I mentioned.

The client won't show you your changes, and even if you tried to POST lol-perks/v1/pages which is the right endpoint, you will get an error if you have the max number of pages used.

How to do it then?

To do it you will need a sequence of requests.

1. Get the current rune page
2. Delete it by Id
3. Create a new rune page

1 - Get the current rune page

By saying get the rune page, I mean to store data about it. But we are going to delete it, why should i store these data then?
Because when deleting a rune page you need to pass the id of the one you want to delete.
To get the current rune page you need to request GET /lol-perks/v1/currentpage.
In my lib the code will be

var data = await leagueClient.Request(requestMethod.get, "/lol-perks/v1/currentpage");

And to get the id from the JSON response look at here
Now we have the id which for this example we will use 123.

2 - Delete it by Id

Once we have the ID of the page we want to delete (current page in this case) we can delete it:

DELETE /lol-perks/v1/page/123
In my lib :

 await leagueClient.Request(requestMethod.delete, "/lol-perks/v1/pages/123");
 // Don't forget we assumed that id is 123, yours will be different 

3 - Create a new rune page

To create a new rune page we use POST "lol-perks/v1/pages" BUT with a body.

What do we need to include in the body?

All you need to specify in the body is

• name
• primaryStyleId Such as these :
  
• subStyleId, which is basically the same as the above one but in the second tree
• selectedPerkIds

As an example... for this page

• primaryStyleId is the id of Precision
• subStyleId is the id of Sorcery
• selectedPerkIds are the inside perks(runes) (Press the attack, Triumph, Legend: Alacrity ....etc)

To make a body for this POST request, it should be like this:

{
    "name":"Ponita",
    "primaryStyleId":8300,
    "subStyleId":8400,     
    "selectedPerkIds": [8351,8313,8345,8347,8451,8444,5007,5002,5001],
    "current":true
}

This will create this rune page

In my lib its like this

  var body = "{\"name\":\"Ponita\", \"selectedPerkIds\": [8351,8313,8345,8347,8451,8444,5007,5002,5001], \"primaryStyleId\":8300, \"subStyleId\":8400, \"current\": true}";
  var request = await PoniLcu.Request(requestMethod.POST, "lol-perks/v1/pages", body);

As you might have noticed, selectedPerkIds is the inside runes and stats

I think that's all, if you still don't understand something feel free to ask ^-^

Credits: Ponita0

Our main two data sources used in this post are:

• game/data/characters/aatrox/aatrox.bin.json
  for Aatrox's champion data and
• game/data/menu/fontconfig_en_us.txt.json
  for the English spell texts.

Finding the correct spell objects

First, we have to find the correct CharacterRecord that contains the paths to the spell objects.  A champion file typically contains multiple character records for different game modes, like URF. We will use the default character record for normal summoner's rift games, which can be found at JSON key Characters/<championName>/CharacterRecords/Root in the champion file. This character root contains a field called: spellNames  which contains all the champion's spells. If you also want the passive spell, you can find it in the mCharacterPassiveSpell field the only difference between the spell names in the passive spell field and the spell names is that the passive spell contains the full path (Characters/Aatrox/Spells/AatroxPassiveAbility/AatroxPassive) and the spell names field contains the following paths: "spellNames":  ["AatroxQAbility/AatroxQ", "AatroxWAbility/AatroxW", "AatroxEAbility/AatroxE", "AatroxRAbility/AatroxR"]. These spell names can be formatted to a full path as follows: Characters/<championName>/Spells/<spellName>. We need these full paths to be able to find the spell's data, as it's located at the JSON value corresponding to the key which is said path.

Spell Maths

To be able to understand the values and ratios spells are comprised of, we must first understand the mathematics. Although a spell object contains way more fields, we will only need the following fields in this post:

• mEffectAmount(optional): Contains static data that scales per level point put into the spell.
• mDataValues: Contains static data that scales per level point put into the spell, but these are mostly used by spell calculations, which we will discuss shortly.
• mSpellCalculations: Contains dynamic game calculations that use a number of variables to determine its value.

Spell Calculations

Before we can continue resolving spell texts, we first need to understand spell calculations. Spell calculations come in 3 different flavours, namely:

• GameCalculation: A normal game calculation
• GameCalculationModified: A GameCalculation but as the name suggests it is modified by a certain modifier or: Modified(gameCalc, multiplier) = gameCalc() * mulitplier
• GameCalculationConditional: A GameCalculation but it contains 3 other game calculations, 1 for calculating which of the other two it should use as value.

In this post we will only discuss a normal game calculation as this is forms a good base. By the time you fully understand a game calculation, you will be able to figure out the other two.

A game calculation contains the following fields:

• mFormulaParts: The parts of type IGameCalculationPart that comprise the final equation
• mDisplayAsPercent: If this is set to true, the final value has to be displayed as (v * 100)%
• mMultiplier(optional): A IGameCalculationPart. If this field is set, the final value is multiplied by the value from this calculation part.

Calculation Parts

There are many calculation parts, of which a large section is known. As we cannot discuss every part, we will discuss the most frequently occurring ones. The other ones can be found worked out here, every file contains a separate calculation part and a method to parse them from JSON files, format the part as string and get their value based on a context containing stats and other values needed to compute some values.

NumberCalculationPart

NumberCalculationPart is the simplest of all calculation parts, as it returns a static 64-bit floating point contained in the mNumber field.

EffectValueCalculationPart

EffectValueCalculationPart returns a value from the  mEffectAmount table based on the mEffectIndex field and the level of the spell (mEffectAmount[mEffectIndex-1][spellLevel]).

NamedDataValueCalculationPart

NamedDataValueCalculationPart returns a value from the  mDataValues table based on the mDataValue field and the level of the spell (mDataValues[mDataValue][spellLevel]).

StatByNamedDataValueCalculationPart

StatByNamedDataValueCalculationPart is very similar to NamedDataValueCalculationPart also using a named data value, but it has 2 additional fields: mStat and mStatFormula. This part calculates its value according to a champion stat in game. A list of all the stats and their respective integer values can be found here. The mStatFormula field is used to determine whether to use the base stat of a champion, the total stat value, or the bonus amount(0 = Base, 1 = Bonus and 2 = Total).

Resolving Spell Texts

To be able to resolve spell texts, we first have to find the correct tooltip text belonging to the spell. The key for this tooltip text can be found at in the client data object of the spell: mClientData→mTooltipData→keyTooltip. In our case for example Spell_AatroxW_Tooltip because the font config uses only lower case keys we first have to convert our key to lower case, so we get spell_aatroxw_tooltip and if we try this key in the font config we indeed find Aatrox fires a chain... now sometimes a key does not exist in the font config for example Spell_VexQ_Tooltip then we can try to find its corresponding hash instead. The hash algorithm used in the font config is XXH64 truncated to 40 bits(a python function for this can be found in the CDTB). So if we try that again with the lower case key, we get the hash 70ad6d3fc2 we can now format enclose this hash in brackets and look for the key {70ad6d3fc2} in the font config we find Vex launches a wave of mist....

Lets take our example tooltip from Aatrox's W:
Aatrox fires a chain, <status>Slowing</status> the first enemy hit by @WSlowPercentage*-100@% for @WSlowDuration@ seconds and dealing <physicalDamage>@WDamage@ physical damage</physicalDamage>. Champions and large jungle monsters have @WSlowDuration@ seconds to leave the impact area or be <status>Pulled</status> back to the center and damaged again for the same amount.
We see a couple things here namely the variables in between two @ characters. In this case these variables are either named data values or spell calculations. If we look at WSlowPercentage we can find it in the data values table with the following values [-0.25,  -0.25,  -0.25,  -0.25,  -0.25,  -0.25,  -0.25] we can also see a * followed by -100 meaning we have to multiple the value from WSlowPercentage by -100 resulting in 25% accros all levels. As for WDamage we can find this in the spell calculations with two parts a NamedDataValueCalculationPart with WBaseDamage and a StatByNamedDataValueCalculationPart with WTotalADRatio and mStat: 2. The calculation will be as follows: 30/40/50/60/70 + 0.4 * AttackDamage. The first values are the values from WBaseDamage now if we look at that field we will see seven values instead of 5 but as a ability can only be used from level 1 and not level 0 we can ignore the first value then the last value can also be ignored because the spell has a max level of 5. There are also cases where a variable will be in a form conforming to @Effect<number>Amount@(e.g., @Effect2Amount@) this means we have to get the corresponding value from the mEffectAmount table based on that number and the level of the spell (mEffectAmount[<number>-1][spellLevel]).

Sometimes it can occur that we cannot cannot find a certain variable be it a game calculation or a datavalue. This issue is similar to what was described earlier with the config but for this we have to use the FNV-1A32 hashing algorithm (a python function for this can be found in the CDTB). When you get the lower case name of the variable and get its hash you can enclose it in brackets like previously mentioned and then try finding it in the data values or spell callculations.

Useful sources:

• https://github.com/moonshadow565/calcrev
• https://github.com/CommunityDragon/CDTB

You want to know where each champion played on Summoner’s Rift.

The Riot API provides role and lane data, but the values are often inaccurate and make it difficult to identify which position a champion played in. There are many different ways of fixing this data, and how you want to fix the data is likely dependent on your use case.

The definitions of “role”, “lane”, and “position” are all similar, but for the sake of this explanation we use the Riot API’s definition of them. The values Riot provides for Role, Lane, and Position are below:

Role: DUO, DUO_CARRY, DUO_SUPPORT, NONE, and SOLO

Lane: TOP_LANE, MID_LANE, BOT_LANE, and JUNGLE

Position: TOP, MIDDLE, JUNGLE, BOTTOM, UTILITY, APEX, and NONE

Fixing the Role and Lane data

We almost always want to use the Position data in our projects, but Riot only returns Role and Lane in the post-match data.

Below are three ways to calculate “correct” Position data.

A simple mapping

The level of accuracy you need is often dependent on your application. For example, if you’re making a website and want to display opponents side by side, it’s probably not the end of the world if 1 in 10 games (10%) are incorrect. The easiest (and most inaccurate) way to correct roles is to just use the Role and Lane data and convert to Position based on the below mapping. This yields about 87.5% accuracy.{ (MID_LANE, SOLO): MIDDLE, (TOP_LANE, SOLO): TOP, (JUNGLE, NONE): JUNGLE, (BOT_LANE, DUO_CARRY): BOTTOM, (BOT_LANE, DUO_SUPPORT): UTILITY }

Use playrates

Alternatively, we can use play rate data (e.g. Lux plays mid 30% of the time and support 70% of the time) to determine where each champion on the team played. This method does not use the Lane or Role data at all, and instead relies purely on playrates. This has the advantage that you can calculate the position of each champion before the game has ended, so it works for apps that use the current-game endpoint. Playrate data can be difficult to calculate by yourself, but the champion.gg API provides this data for the current patch. If you want playrate data for previous patches, you’ll have to calculate it yourself by pulling a bunch of matches from the Riot API and calculating the statistics. An implementation of this algorithm can be found here: https://github.com/meraki-analytics/role-identification. This yields accuracies in the ~ 95% range.

Use timeline data

Finally, we can use most-match data in the timeline objects to identify the position on the map of the champions throughout the game. We can also look at items, runes, summoner spells, etc. to help narrow down what position the champion likely played in. This is easiest implemented using a machine learning approach. Training data can be found here: https://github.com/Canisback/roleML/blob/master/data/verification_results.csv. An implementation of an SVM (a machine learning model) to identify lanes and roles can be found here: https://github.com/meraki-analytics/role-identification/blob/timeline/timeline-roleidentification/finished_timeline_roleID.ipynb that you can use as an example for your own model. A decision tree is another good machine learning algorithm for this task.

Other useful data

You may also want to consider the history of the summoner playing the champion. For example, you might look at their recent games and see that they played mid 80% of the time. There’s then a good chance that they are playing mid in other games as well. This won’t be a perfect predictor, but this information may improve your method.

Credits: WxWatch

• See the PUUIDs and Other IDs section for information about summoner IDs, account IDs, and PUUIDs.

Tournaments

—

Match

• Matches are kept for 2 years, timelines for 1 year.
• The creation date timestamps in milliseconds (not seconds).
• The pick order of participants is 0-5-1-6-2-7-3-8-4-9.
• The totalGame fields is incorrect in most cases. It’s best practice to just ignore it.
• Season ID’s should only be used if you’re looking for data that’s over a year old, as it can take months for the ID’s to be updated for the current season. Because of this, it’s best to use timestamps instead. You can find the approximate start time for each season here.
• You can find seed data for matches at these urls: https://s3-us-west-1.amazonaws.com/riot-developer-portal/seed-data/matches1.json … https://s3-us-west-1.amazonaws.com/riot-developer-portal/seed-data/matches10.json

Custom Data

• Currently, custom game data (excluding the tournament system), is not retrievable from the API due to privacy policies. Riot is slowly but surely working towards an external RSO (Riot Sign-On) solution that will allow individual players to “Okay” websites to use their custom game data.

Verification

RSO is Riot Sign-On, the login logic you see whenever you access anything that requires your Riot account. RSO is not yet ready for the public to use, but Riot has implemented a work-around for websites to verify users.

Websites should generate a random string for the user to input into their client. See this gif for an illustration. The verification endpoint is notorious for having issues. The user may need to restart their client a few times to get it working, or try again later.

Current Game

• Spectator time is not accurate and inconsistent. See this issue for more details.

Replay Files

• Reverse engineering spectator (.rolf) files is not possible and against the Terms of Service. The encryption of the .rofl files changes each patch. This is to prevent cheating.

Credits: WxWatch

The best way to collect a large set of matches is not straightforward. Typically you need code that does this:

1. Collect a few summoners by hand. Just your own summoner is likely enough, or you could use all challenger players.
2. Get the account IDs of those summoners.
3. Get their match history on the queue type you want (paginate as far as you want to go, or filter by patch).
4. Success! You have a ton of match IDs, from there, you can fetch their timelines or parse the matches however you want.

Alternatively, Canisback on the Discord currently hosts a list of matches IDs that you can use to pull summoners from the matches/{matchId} endpoints. These lists are provided for free to the community for use, and may go down or stop being updated at any time.

Summoner Data

You can collect summoner data similar to how you collect match data (see above).

You can also use the League endpoints to get lists of ranked summoners. The positional league endpoints provide a paginated list of all summoners in a Tier + Division + Position (e.g. all ranked Diamond II Top laners). Alternatively, Canisback on the Discord currently hosts a list of league IDs that you can use to pull summoners from the leagues/{leagueId} endpoints. These lists are provided for free to the community for use, and may go down or stop being updated at any time.

Credits: WxWatch

Because the Replay API is fairly new, the best place to start are the doc pages from Riot about the Replay API and League Director.

Credits: WxWatch

If your project is only intended for personal usage, you can modify your browser settings to disable CORS (the mechanism which blocks you from making client-side calls). However, you will not be allowed to publish your site if you do this. More info about disabling CORS can be found here.

You can create a mobile app that uses the API, but you’ll need to create a webpage to explain the app, and a server to proxy your API calls. The website should contain enough information so that Rioters can evaluate your project (to ensure it isn’t breaking any rules) without actually downloading it. You’ll also need to set up a server to make your API calls from. You cannot securely store your API key in a distributed app, so your app will need to communicate with a server, which will in turn communicate with the API.

Credits: WxWatch

This page contains up-to-date information for which endpoints you are allowed to use.

It’s important that you create an application on the dev portal telling Riot how you are using the LCU in your project. The more information they have about how people are using the LCU, the better feedback they can give to other teams at Riot.

The LCU must be running on your computer, and you must be logged in, in order to use the LCU endpoints.

Rift Explorer

Pupix on Discord created an excellent app called Rift Explorer to explore the LCU endpoints. You can download it here.

Vivi on Discord create a website that allows you to view the swagger for the LCU endpoints online.

Tips

Starting the LCU with the flag --mode unattended will allow you to use some of the LCU endpoints without logging in. This is convenient for running the LCU on a headless (no-monitor) server.

You can create a normal game mode lobby by passing the queue ID ({"queueId":430}) to the /lol-lobby/v2/ POST endpoint.

To create a custom game lobby, use the below POST request. Change PRACTICETOOL to CLASSIC if you don’t want it to be a practice game.

POST /lol-lobby/v2/lobby { "customGameLobby": { "configuration": { "gameMode": "PRACTICETOOL", "gameMutator": "", "gameServerRegion": "", "mapId": 11, "mutators": {"id": 1}, "spectatorPolicy": "AllAllowed", "teamSize": 5 }, "lobbyName": "Name", "lobbyPassword": null }, "isCustom": true }

These flags are useful: --app-port=1337 --headless --allow-multiple-clients.

If you are running on Linux with Wine, you need to set the Wine prefix to Windows XP and have wine-staging for compatibility with the anti cheat.

Credits: WxWatch

Summoner and account IDs are only unique per region, and PUUIDs are unique globally.

Because the PUUID is globally unique, when a player transfers regions their PUUID will not change. This allows you to track summoners that have transferred regions. If a player transfers regions, their summoner and account IDs will change.

All IDs are encrypted using encryption keys unique to each project. An ID obtained with your dev key will not work with your production key (and vice versa). When you refresh a key, the encrypted ID will not change.

Credits: WxWatch

Do not apply for a project if you just want to test the API. If you are developing a project or just testing things out, use your development key that Riot gives you automatically when you signed up. This key expires every 24 hours, so you need to refresh it every day that you work on your app. This is deliberate functionality and your project will not be given a non-development key if all you are doing is testing the API. Even the Rioters use development keys that expire every 24 hours.

Applications take ~ two weeks (10 business days, barring holidays) to process. Make sure it’s verified (riot.txt). If it’s been longer than two weeks and you didn’t change your application during that time period, ask a Guru on Discord for help.

You can find your app ID by going to https://developer.riotgames.com/apps, selecting your project from the list on the left, and copying the number in the URL (https://developer.riotgames.com/app/YOURAPPIDISHERE/info).

Production App

Register your project to apply for a Production API Key with access to the Standard APIs and/or Tournaments API. A Production API key requires a working prototype. Production API keys are not for testing purposes. You may submit an application in the planning stage of your project, but your application for a production key won’t be approved until your project is ready for public consumption. Work in progress should be tested using your demo key.

Personal App

Register your project to apply for a Personal API Key without the verification process. This is only for the Standard API’s, not Tournaments. Personal Keys require a detailed description of the project.

Credits: WxWatch

If you can’t find what you’re looking for in ddragon, look in cdragon. This is a useful link to start at. If you can’t find what you’re looking for because there’s so many files and folders to go through, ask on Discord for help.

One commonly sought-after set of images are the rune stat images, which can be found here.

Credits: WxWatch

You can download the entire set of data and images by downloading this tarball (make sure to change the * version * to the latest patch): https://ddragon.leagueoflegends.com/cdn/dragontail-9.3.1.tgz. The file is about 0.5 GB.

You can also access individual files by going to specific URLs, for example: http://ddragon.leagueoflegends.com/cdn/9.3.1/data/en_US/champion.json.

Caching

Because the data in ddragon only changes when new patches come out, you can cache the data by saving it to your computer. Your app can then load the data from disk rather than requesting it over the www. This will speed up your app and reduce the load on Riot’s servers, which ensures the servers don’t go down due to abnormally high usage.

In general, it’s a good idea to cache data that you will use often and that doesn’t change often.

Common Issues

• If You can’t find something in ddragon, Look in cdragon or ask on Discord.
• The image filenames for champions, items, etc. can be found by looking at the image.full fields in the json data.
• Monkeyking. Yes, Wukong’s internal name is monkeyking. You can identify the correct internal name for every champion by looking at the key attribute in the champion.json file.
• The data in ddragon is inaccurate, especially champion spell data and item stats. This is an unfortunate situation that is surprisingly difficult to solve. If you want to know why, you can ask on Discord. There is no perfect or even close to perfect source for champion spell data, despite significant effort. The League Wikia is your best resource.
• If a new patch came out but ddragon hasn’t updated, wait a little while. Sometimes it takes two days after a patch for the new version of ddragon to be released. Other times ddragon is two days ahead of the patch.
• Data from Data Dragon is encoded using UTF-8. To ensure you receive a properly encoded response include the Accept-Charset header specifying UTF-8 as the desired response encoding.
• Other issues: You may be able to find some information by searching the github issues, otherwise ask on Discord.

Most Recent Version

You can get the latest version of ddragon from the version.json file.

Because patches get released on different regions at different times, one region may be on the new version of ddragon while another region may be be on an old version. You can check which patch a region is on by looking at the realms files for each region. The one for North America can be found at https://ddragon.leagueoflegends.com/realms/na.json. The exact time the patch gets released on a region may not correspond to exactly when the corresponding realm file is updated to the new patch.

Patch Data

ddragon does not provide data for when patches were released. Instead, you can find this data on cdragon’s github. See the readme on github for information about how to use the file.

Languages

The languages supported by ddragon can be found here.

Credits: WxWatch

This guide will help you regenerate your API key.

Developer Keys

Step one:

Head to the developer portal and scroll down and complete the captcha and click regenerate

Production Keys:

Step one:

Head to the developer portal and go to your app.

Step two:

Select your app and regenerate your key by clicking new API key and confirming it.

Best Practices

To best utilize TFT match history there are two things to keep in mind; match history is still evolving and fresh data is cheaper.

Response Body Structure

A basic version of TFT match history was released in the client in patch 9.19. If you look up matches played during this patch they'll return data_version: "1" which is used through patch 9.20. In patch 9.19, the only fields for a participant that are guranteed to be accurate are last_round, level, placement, and puuid. In patch 9.20, items were added to the response body but were not guranteed to be accurate. As of patch 9.21 all the fields in the response should be accurate. As of patch 9.22, a new field called character_id was added to the UnitDto and the data version was bumped to data_version: "2".

Fresh Data

The match history service itself is optimized for fresh data. The newer the matches, the cheaper the cost to look them up. With Set 2 launching on November 4th, 2019 and the data inconsistencies prior to patch 9.20, we’re discouraging developers from backfilling data for Set 1.

Credits: @SKarajic