The PUBG Game Data Service makes it easier for users to have open access to in-game data, which developers can use to build awesome tools and services.
This service is designed to implement the required features of the JSON-API specification. Data returned from each of the API’s endpoint will be in JSON-API format. You can find additional information about the specification here.
We created the API’s endpoint documentation using the OpenAPI specification. This means that users can interact with the endpoint documentation to see how it works in action, generate commands, and get a feel for what the returned data will look like with no technical experience or coding knowledge required! On an endpoint documentation page, click the green “Authorize” button with the lock symbol and enter your API key. With that done, just click “Try it out” on any endpoint and use the “Execute” button to send a request.
Data dictionaries and enums can be found on GitHub.
We recommend taking a look at the FAQ for the answers to some common questions. You can also visit the forums or join the official PUBG Developer API Discord server to meet, chat, troubleshoot, and collaborate with other community developers and designers.
An application using the API will typically have the following components:
A client-side app
This is the user facing part of the application. It takes in user input, makes a request to the backend, and displays the results for the user. This could be represented as a standalone website, Discord bot, mobile app, or anything else you can think up.
A backend server
This is the core logic of the application. It receives requests from the client-side app, makes appropriate requests to the API, processes the data received, stores it in the database, and returns it to the client-side app.
A database structure
This is where the aggregated data is stored. Depending on what your application does, this could be player records, match history, leaderboard standings, or anything else it needs to hold on to.
A caching layer
This component sits between the backend server and the API. It speeds up user requests and reduces the number of calls to the API by storing API responses in memory. We will get more into the details of how this works in the Caching Overview and Caching Implementation sections.
The API
Added for visualization in the stack, this is the PUBG API.
The data provided by the PUBG API can be used in many ways to create a variety of applications. It is important to understand the intended uses of this data, and how the data and endpoint structure reflect that vision.
The primary API endpoints (players and matches) are structured to favor specific searches, and not to provide access to all data. This is why the API flow starts with searching for specific players. In general, applications should try to stick to an opt-in flow, as opposed to trying to search for all players. Here are some examples of how this flow could fit into some of the expected use cases:
-
Stat sites & bots - A user must enter their player name to see their stats and history, meaning that the application only needs to query the API when that happens
- Leaderboards & coaching services - Users must register on the site, meaning that the application only has to query for known players
This being said, some applications may still need to analyze large amounts of random data. This can be done by requesting sample data, which is a randomized statistical sample that can be used to infer and understand global changes. This data can be acquired from the samples endpoint.
Generally speaking, applications should try to avoid querying for the same data twice whenever possible. This is where caching comes into play. When the backend makes a request to the API, the results should be cached so that they can be reused for a set period of time.
For example, lets say that your application takes a player’s IGN as input and displays their stats and match history. The first time the player is looked up by the service, the application will have to query the API to get their data. The caching layer then holds onto those API responses for a set amount of time, lets say 30 minutes. If the player is looked up again within that window, the results will be returned from memory without needing to call the API. After that window has passed the cached data will be removed. The next time that player is looked up the cycle will repeat (query API –> store in cache –> remove after 30 min).
There may also be an opportunity for caching results from the backend server depending on how your application works. This can help cut down on requests to your database or other storage structure.
In this section we will cover how to cache API responses at a high level. Please note that the code examples shown below are in GO, and do not include error handling.
To start, let’s take a look at an example function that gets a player object, which we will assume is a structure containing relevant player data for our application needs:
This function will make a request to the API each time it is called for a specific player. This can be very inefficient considering that player records in the API are not updated frequently (at minimum, the time of a single match plus a little bit for processing time). To improve this, we can surround the existing functionality with a check for the player in the cache. In addition, we also now need to remember to store the player object in the cache when we do get it from the API. It will look something like this:
Here are some examples of caching software:
- Memcached - A fairly easy to use caching software with wrappers in many programming languages.
- Redis - A more complex caching software offering more flexibility and features
We require that a JSON Web Token JWT be sent along with requests via the Authorization header. There’s no need to create JWTs manually since they will be created for you when you register for the API - Register at https://developer.pubg.com to receive a free API key with a rate limit of 10 requests per minute. You can find more information about rate limits on the Rate Limits page.
JWTs are passed as bearer tokens in the Authorization header, and look like the following:
Authorization: Bearer api-key
Remember when developing a website/web application that your API key should never be stored client side. Calls to the API should only be made from a secure server side application.
The TitleID for a request is determined by the API Key and sent in the Authorization header automatically. Some objects may have a titleID field specifying the game title associated with the data returned.
To ensure the availability and stability of the PUBG API, each API key has a limit on the number of requests it can be used to make per minute. The default rate limit is 10 requests per minute for testing/development purposes. When you have exceeded the number of available requests you will receive an HTTP 429 error code (too many requests), but you should be able to make requests again within a minute.
The rate limit headers are defined as follows:
X-RateLimit-Limit - Request limit per day / per minute
X-RateLimit-Remaining - The number of requests left for the time window
X-RateLimit-Reset - The time that the rate limit will be reset, as a UNIX timestamp
Expected rate limit usage
Since the /matches and telemetry endpoints are not rate limited, the amount of rate limited requests a typical application needs to make to the API should be directly proportional to the number of users/players using it. For example, each time a player is looked up, the application needs to make two requests (if the information is not already cached):
-
one to “/players?filter[playerNames]={playerName}” or “/players/{accountId} if the accountId is already known”
-
one to “/players/{accountId}/seasons/{seasonId}” if season stats are required for the use case
Any following requests to the /matches or telemetry endpoints will not count against the application’s API key rate limit.
Requesting a higher rate limit
If you find that the default (10RPM) rate limit is not sufficient for your application, you can request a higher limit by selecting “I NEED A HIGHER LIMIT” in “MY APPS”. Please keep in mind that we require some form of working sample and an explanation of the need for a higher limit in order to approve rate limit increase requests.
{
"type": "season",
"id": "$seasonId",
"attributes": {
"isCurrentSeason": true,
"isOffseason": false
}
}
Please make sure that you fill out the form completely with as much detail as possible, and we will work with you to provide a more appropriate limit.
In order to determine an appropriate rate limit for your application, we need to know how many API requests your application makes, when it makes them, and analytics showing the number of users if you have active users. We will also want to know about the caching and optimization strategies you are using in order to help reduce the number of API requests that your application requires. Please take a look at our Caching Overview and Caching Implementation sections for additional information.
"matches": {
"data": [
{
"type": "match",
"id": "matchId"
}
]
}
If the project you are working on has a barrier to entry, please provide all the necessary information on how to access your site.
If your rate limit request is approved, you will receive a notice that the rate limit has been increased for your application.
We follow SEMVER standards, using a MAJOR.MINOR.PATCH versioning scheme. This means that we will increment versioning in the following way:
-
MAJOR version when we make incompatible API changes
-
MINOR version when we add functionality in a backwards-compatible manner
-
PATCH version when we make backwards-compatible bug fixes
There are two seperate version numbers that users should be aware of. One for the API service, and one for the data returned by the API. Versioning is seperated in this way because changes to the service may be rolled out that do not affect the PUBG API data. The version of the API service is available in the data returned by the /status endpoint. The data version can be found in the changelog.