ZOOM Platform Library Integration Docs

We are undergoing a complete rework of our entire infrastructure when it comes to downloading, installing, and updating our titles.
Part of this rework will include an open and fully documented spec including auth, downloading, parsing and installation for every platform so that anyone can implement our library with their launcher of choice.

Until that is complete and ready for the public, here is some documentation on how library integration can work with our current installers. These docs will be periodically updated and the API will be updated within the restrictions of the current installer workflow. There will be no official integrations using this API.

This documentation will not cover the JSON responses or how to handle them. They are mostly self-explanatory. See existing implementations if you need a reference.
If you have any questions or need more information, email jmartinez@[the domain you're on] or message zennn on Discord.

This documentation is available as markdown at /li/docs.md.

REST API

Authentication

Use the regular /login page to login and save the API key after login. This key will only work with the endpoints below.

You may add the ?li= query parameter with your app name as the value for a minimal login page. Example: /login?li=lutris
Once logged in, the user will be redirected to /account. You can make the redirect have the token value in the URL with the return_li_token=true param. Example: /login?li=lutris&return_li_token=true

The token will be in the URL as ?li_token=li_XXXX

Making Requests

Every request should have these headers set:

All responses will return 401 Unauthorized if the auth token is invalid. The token will invalidate after a password reset, so you will need to log in again to get a new token.

Rate Limits

All endpoints are rate limited. If limits are reached, they will respond with:

Be sure to handle this in your implementation.

Check if User is Authenticated

If GET is used, the response body will contain an identifier for the user, you may use HEAD if your implementation doesn't need a response.

Methods
GET, HEAD
Path
/li/loggedin

Response:

Get Games Owned by User

Retrieves a list of games owned by the user, along with metadata for each.

Method
GET
Path
/li/games
Query Params
page: Should start at 0 and increment based on total_pages in the response.

Response:

Get metadata for a single Game

Method
GET
Path
/li/game/{gameId}
Path Parameter
gameId: Game UUID

Response:

Get Files for a Game

Method
GET
Path
/li/game/{gameId}/files
Path Parameter
gameId: Game UUID

Response:

Get metadata for a single File

Method
GET
Path
/li/file/{fileId}
Path Parameter
fileId: File UUID

Response:

Get File download info

Only call this endpoint when you're ready to start the download.

Method
GET
Path
/li/download/{fileId}
Path Parameter
fileId: File UUID

Response:

Installer Info

Notes on extracting installer files

You should let users install games by going through the installation process. Many games have post install tasks that are required for the game to work. And many add required registry entries based on the system.
If you decide to "install" games by extracting the installer, these post install tasks won't run and some games will not work at all.
Installing DLC also requires a proper base game install.

Another reason to not extract installers is that some installers will have options only available via the UI.
Example: Duke Nukem Manhattan Project allows the user to choose between the Original or Enhanced edition.

You can reduce some of the installer windows by using an .inf file and pre-adding some registry entries that the installer would add.

Getting game info