InternalSteamWebAPI: a wiki of Steam's undocumented web endpoints

What counts as the Steam Web API here

The repository's stated purpose is documenting the unofficial and internal Steam Web API, and the README is careful to draw a boundary immediately. It says the wiki is not intended to list or document any official API that typically uses an API key, and points readers who want that to the Steam Web API Documentation by xPaw. The distinction matters because the two are used differently. The official API is key-authenticated and contracted, so you can rely on it. The internal API is what the Steam client and the web store actually call, and it is not contracted at all. The audience for this project is therefore a developer who has run into a request in the browser network panel, or in a Steam client log, and needs to know what it takes and what comes back. The topics attached to the repository confirm the framing, with reverse-engineering, api-docs and steampowered among them.

The wiki is the product, the repository is the build script

This is a project whose published output lives somewhere other than its own tree, and that arrangement is worth understanding before you start reading it. The README's own access panel points to a wiki hosted on GitHub under a different repository name, UnofficialSteamWebAPI, while the repository you are reading is named InternalSteamWebAPI. The package.json tells the same story from the build side, with the name unofficial-steam-web-api, the version at 1.0.0, and the homepage pointing at the wiki rather than at the repository. The build scripts show how the documentation reaches that wiki.

        "build": "gwtc -t \"Unofficial Steam Web API Documentation\" ../UnofficialSteamWebAPI.wiki",
        "build:alt": "gwtc -t \"Unofficial Steam Web API Documentation\" --logo-img ./logo.png --highlight-theme vs2015 ../UnofficialSteamWebAPI.wiki"

The tool doing the work is github-wikito-converter, listed as the only devDependency, invoked as gwtc with a title and a target wiki directory. The primary language of the repository is HTML, and documentation.html at the top level is the single page that gets converted. There is also a generator/ directory, and the logo.png that the alternate build script passes in. So the repository holds a source document, a converter configuration and a helper script, and the wiki is where the result lands.

generate_docs.js proposes an entry, you finish it by hand

The README describes a JavaScript script, generate_docs.js, that may help you generate a proposal of the API documentation of an endpoint. The script is the part of the project with actual code in it, and its limitation is stated just as plainly as its purpose. It is not able to detect variables, such as appids and steamids, and you have to correct this manually. That constraint is the nature of the problem rather than a bug in the tool. A request to an internal endpoint usually carries identifiers in the path, and the script cannot tell an appid from a literal segment, so a generated proposal is a draft with placeholders in it.

In practice that means the script saves you the shape of the request and the field names of the response, and leaves you to supply the values and to check that the entry reads correctly. A contributor who wanted to add an endpoint would run the script, correct the detected variables, and then write the prose around the example.

Where the endpoint knowledge comes from

The README says most of these unofficial API endpoints can be found by reverse engineering, and links a Chrome developer tools tutorial on the network panel as the method. That is the whole workflow: open the Steam web store or the client, watch the requests, and record what you see. The tooling is a browser. Alongside that, the README names other projects that are tracking the same endpoints, and lists two of them: SteamTracking's Client URL List, which is a list of URLs extracted from the client, and SteamTracking's JavaScript URL List, which covers the web side. Those lists are raw input rather than documentation, and the value of this project is that it turns them into something you can read, with the parameters and the response fields described.

That derivation is also the project weakness. A wiki entry exists because somebody looked at a request, and the README's request for contributions says the project desperately seeks contributions to the wiki to keep the documentation up to date and complete, and asks contributors to look out for TODO markers and add a new wiki entry or update an existing one. The TODO markers are the honest signal of which parts of the documentation are known to be incomplete, so an entry with a TODO is a different thing from a finished one.

An unofficial API is an unstable contract, and that is the trade

Nothing here is guaranteed to keep working, and the project is candid about the reason. Because of the nature of this kind of API, the README says, contributions are needed to keep the documentation up to date and complete. An internal endpoint is one Steam could change, rate limit or remove without notice and without a changelog, because there is no contract behind it. The official key-based API exists precisely so that consumers do not have to depend on undocumented behaviour.

That makes this documentation best used for understanding and for research, and riskier as a production dependency. If your code calls an internal endpoint in a shipped product, you have accepted that the endpoint can change under you, and the documentation only tells you what the behaviour was when somebody looked. The right way to think about it is that this wiki shortens the reverse engineering phase, it does not remove it. You still need to observe the live behaviour before you trust it, and you need a plan for what happens when the field you depend on disappears.

There is also a scope limit worth naming. The README says the wiki is not intended to list or document any official API, and sends you elsewhere for that. So this is not a general Steam developer reference, it is one specific slice of the surface, and a developer who needs the store API for a game listing should be reading the xPaw documentation instead.

Who should read this and who should not

Two profiles suit the project. The first is a developer reverse engineering a Steam interaction, who needs the request shape and the response fields today and is prepared to check them against live traffic. The second is a documentation contributor, because the README's central request is for help keeping the wiki current, and the mechanics of contributing are documented: find the entry marked with a TODO, or add a new one, and correct the variables the script could not detect. The repository takes part in Hacktoberfest, which is one route in.

Two profiles should not start here. A team building a product against Steam's public interface should use the official API with a key, because that is the interface Steam intends to support, and a team that has been asked to guarantee uptime cannot base a service on endpoints that change without notice. The honest summary is that this repository is a shared research notebook for a surface that has no contract, and its maintenance model is whoever happens to be looking that week.

Editorial conclusion

InternalSteamWebAPI fits a developer who has to talk to a Steam endpoint that has no official documentation and needs to know the field names and the request shape, and who is willing to treat the result as reverse engineered rather than supported. It does not fit anyone who needs a stable, key-based contract, because the whole point is that Steam does not publish one, and it does not fit a production service that cannot tolerate an endpoint changing without notice. Before you depend on it, read the wiki entry for the specific endpoint rather than the repository README, because the README is a pointer to a wiki that is maintained separately, and check the TODO markers the README asks contributors to look out for, since those mark entries that are known to be incomplete.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. Revadike/InternalSteamWebAPI on GitHub