The unofficial VALORANT API runs on Riot's in-game API and gates its keys by use case

The data comes from the in-game API, not from a public API

The project description is short: an unofficial VALORANT API using the VALORANT Ingame API. The JavaScript repository is the client library, and the hosted service behind it is the thing you actually call.

That distinction is the whole design. Riot's official API is gated behind RSO and is not aimed at this kind of use, so the service authenticates with a player account against Riot's own in-game endpoints and republishes what it finds. The library in this repository, in a package/ directory next to the README, is the JavaScript client for that hosted API.

The repository is thin for a reason. There is a README.md and a package/ directory, and the actual documentation lives on a separate documentation site at docs.henrikdev.xyz, with an OpenAPI spec available at the API's own docs path. The status of the service is published on a status page, and keys are managed in a dashboard at api.henrikdev.xyz/dashboard.

So the project is a hosted service with a thin client, and the documentation and the service, not the repository, are where you find the details.

Keys are tiered by what you intend to build

The API party uses a key based system, and the tiers are chosen by use case rather than by price alone, which is unusual and useful.

The Basic Key is instant, with no waiting time, and gives 30 requests per minute. The documentation says it is suitable for Twitch bots, educational purposes such as how do I code, and private Discord bots. The Enhanced Key is applied for and the maintainer says you will receive an answer within one to two weeks, sometimes faster, and it raises the limit to 90 requests per minute, suitable for public Discord bots and public websites. Above that sits a Production and Custom Key where the rate limit is the one you requested, intended for large Discord bots and large websites, with the note that the API is not intended for production use and a grant will only happen with a valid reason.

The rate limits are the same for every endpoint, so 90 requests per minute with an Advanced key is a budget for the whole application rather than per endpoint.

To get a key at all you have to join the linked Discord, and the documentation is explicit that this is for support reasons. You also have to enter details about your app, such as the use case, to ensure the API is not used in a harmful way and that the user knows their data is used.

The three tiers are therefore a workload classification mechanism. You declare what you are building, and you get the limit that fits it.

What the API refuses to do, and why

The documentation has a section headed IMPORTANT that lists what is not allowed, and the reasoning is the most useful part of the README.

Big analytic projects are not allowed. The stated reason is data privacy: Riot set RSO as a requirement for their official API because the VAL Team said they want to protect the users data, and the maintainer says it is a requirement so as not to get into trouble with Riot and to keep the API running as long as possible for normal developers.

Public store checkers are not allowed, and the reason is credential handling: as this feature requires the users credentials, the possibility of a credential leak is too high.

TOS breaking stuff is not allowed, which the documentation expands to include showing hidden names, account checkers for selling accounts and other stuff that may sound illegal, with a request to do some thinking before executing.

The first requirement is stated even earlier in the document. Please make sure that the user has given his consent to use his data, and analytic services where the user has not given consent are not supported and will be banned if found out, with the same rule applied to store checkers if they are public.

This is an unusual posture for a game data API, and it exists because the service authenticates as a player. That is a real constraint on what you can build with it, and it is written down before you write any code.

Rate limits return a structured 429, not a dropped connection

The rate limit behaviour is documented with an example, which is a good sign about how the service treats its users.

All rate limits are the same for every endpoint, and if you exceed the rate limit you get a JSON body with a 429 status code.

{
  "status": 429,
  "errors": [
    {
      "message": "Rate Limited",
      "code": 0,
      "global": false
    }
  ]
}

The shape is worth reading. The status is a number, the errors array carries a message, a numeric code and a global flag that presumably says whether the limit applies across the API or to one endpoint.

There are also rate limit adjustments per tier, and the same three buckets appear in the tier list: 30 requests per minute for a Basic key, 90 for Enhanced, and whatever you asked for on a Custom key.

For a client library, the practical consequence is that your retry logic has something to parse. The body is stable enough to build a backoff on, and the global flag tells you whether backing off helps or whether you have hit a ceiling that applies to the whole key.

Every client library in the table is behind

The wrapper table is the most revealing part of the README, because it lists the client libraries in other languages and then marks each one as out of date.

| Language | Repo | API Version | Up To Date? | Documentation (if available)
| :-: | :-: | :-: | :-: | :-: |
| JavaScript | This Repo | v2.3.0 | ❌ | - |

The JavaScript library in this repository is at API version v2.3.0, the Python wrapper ValorantAPI is at v3.0.2, the Java wrapper JVA at v2.6.2, the C# wrapper Valorant-NET at v1.6.2, and the Go wrapper go-valorant-api at v3.0.2. Every row is marked as not up to date.

So the table is really a list of alternatives, and the honest reading is that the client libraries lag the hosted API, including the one in this repository. If you are picking a language, the Go and Python wrappers are closest to the current API version, and each of them has documentation linked, which the JavaScript, Java and C# rows do not.

Two other projects are listed as using the API: Henrik-3/valorant-labs and the VALO DE Discord role system.

For images from the game, the documentation points at a separate site, valorant-api.com, and the contributors credited are @liamcottle, @RumbleMike and @Hamper, with the note that without them parts of the API would not be available.

One maintainer, one server, and an explicit legal position

The legal section is short and direct. This API is not endorsed by Riot Games and does not reflect the views or opinions of Riot Games or anyone officially involved in producing or managing Riot Games properties, and Riot Games and all associated properties are trademarks or registered trademarks of Riot Games, Inc.

The tone of the project is personal throughout. The maintainer addresses Riot directly in the README, saying he hopes they know this project is a try to enhance the developer community of VALORANT and to recognize it as one, and invites them to get in touch on Discord. Hosting costs are acknowledged directly, and the project asks for compensation through a Patreon subscription at level four or five for projects that need higher rate limits or that have a paid tier, with the reasoning that the maintainer should be compensated for hosting costs, storage and the hours already spent on the project.

The custom rate limit arrangement is decided case by case, and the documentation says you will be required to subscribe, individually decided based on the project, or to have a paid tier.

What this means for an adopter is that the service is one person's infrastructure and one person's policy. The status page exists because outages matter, the Discord exists because support is the point, and the not endorsed line is not a formality but the reason the scope is deliberately narrow.

Editorial conclusion

unofficial-valorant-api fits a developer building a small community tool, a Discord bot or a research script that needs VALORANT account and match data, because the tiered keys make the limits explicit and the rate limit response is documented. It does not fit a product that needs an official and supported data source, since the project is explicitly not endorsed by Riot Games, and it does not fit an analytics product at scale, because the maintainer's own policy bans big analytics projects for data privacy reasons. Before building on it, read the consent requirement at the top of the documentation, pick the key tier that matches your use case, and check the status page and the OpenAPI spec rather than assuming the endpoint set is stable, since the wrapper table shows every client library lagging behind the current API version.

Frequently asked questions

Official sources

1. Henrik-3/unofficial-valorant-api on GitHub
2. Issues
3. README
4. Releases