From 9b17d59cf66444fbd1834c1bfa4f41cb6fc7d3de Mon Sep 17 00:00:00 2001 From: Paul Vogel Date: Mon, 10 Nov 2025 14:06:35 +0100 Subject: [PATCH] Rerun with openapi-generator on v7.17.0 --- docs/Api/MiscApi.md | 10 +- docs/Api/NotificationsApi.md | 2 + docs/Api/ProjectsApi.md | 6 +- docs/Api/TagsApi.md | 2 + docs/Api/TeamsApi.md | 2 + docs/Api/ThreadsApi.md | 2 + docs/Api/UsersApi.md | 62 ++ docs/Api/VersionFilesApi.md | 2 + docs/Api/VersionsApi.md | 2 + docs/Model/Statistics.md | 2 +- lib/Api/MiscApi.php | 268 +++--- lib/Api/NotificationsApi.php | 391 +++------ lib/Api/ProjectsApi.php | 789 +++++------------ lib/Api/TagsApi.php | 725 +++++---------- lib/Api/TeamsApi.php | 297 +++---- lib/Api/ThreadsApi.php | 762 +++++----------- lib/Api/UsersApi.php | 830 +++++++++--------- lib/Api/VersionFilesApi.php | 347 +++----- lib/Api/VersionsApi.php | 522 ++++------- lib/ApiException.php | 8 +- lib/Configuration.php | 69 +- lib/HeaderSelector.php | 8 +- lib/Model/AuthError.php | 20 +- lib/Model/BaseProject.php | 20 +- lib/Model/BaseVersion.php | 20 +- lib/Model/CategoryTag.php | 20 +- lib/Model/CreatableProject.php | 20 +- lib/Model/CreatableProjectGalleryItem.php | 20 +- lib/Model/CreatableReport.php | 20 +- lib/Model/CreatableVersion.php | 20 +- lib/Model/DonationPlatformTag.php | 20 +- lib/Model/EditableFileType.php | 20 +- lib/Model/EditableProject.php | 20 +- lib/Model/EditableUser.php | 20 +- lib/Model/EditableVersion.php | 20 +- lib/Model/ForgeUpdateCheckerPromos.php | 20 +- lib/Model/ForgeUpdates.php | 20 +- lib/Model/GalleryImage.php | 20 +- lib/Model/GameVersionTag.php | 20 +- lib/Model/GetLatestVersionFromHashBody.php | 20 +- lib/Model/GetLatestVersionsFromHashesBody.php | 20 +- lib/Model/HashList.php | 20 +- lib/Model/InvalidInputError.php | 20 +- lib/Model/License.php | 20 +- lib/Model/LicenseTag.php | 20 +- lib/Model/LoaderTag.php | 20 +- lib/Model/ModelInterface.php | 8 +- lib/Model/ModeratorMessage.php | 20 +- lib/Model/ModifiableProject.php | 20 +- lib/Model/ModifyReportRequest.php | 20 +- lib/Model/ModifyTeamMemberBody.php | 20 +- lib/Model/NonSearchProject.php | 20 +- lib/Model/Notification.php | 20 +- lib/Model/NotificationAction.php | 20 +- lib/Model/PatchProjectsBody.php | 20 +- lib/Model/Project.php | 20 +- lib/Model/ProjectDependencyList.php | 20 +- lib/Model/ProjectDonationURL.php | 20 +- lib/Model/ProjectIdentifier.php | 20 +- lib/Model/ProjectLicense.php | 20 +- lib/Model/ProjectResult.php | 20 +- lib/Model/Report.php | 20 +- lib/Model/Schedule.php | 20 +- lib/Model/SearchResults.php | 20 +- lib/Model/ServerRenderedProject.php | 20 +- lib/Model/Statistics.php | 22 +- lib/Model/TeamMember.php | 20 +- lib/Model/Thread.php | 20 +- lib/Model/ThreadMessage.php | 20 +- lib/Model/ThreadMessageBody.php | 20 +- lib/Model/User.php | 20 +- lib/Model/UserIdentifier.php | 20 +- lib/Model/UserPayoutData.php | 20 +- lib/Model/UserPayoutHistory.php | 20 +- lib/Model/UserPayoutHistoryEntry.php | 20 +- lib/Model/Version.php | 20 +- lib/Model/VersionDependency.php | 20 +- lib/Model/VersionFile.php | 20 +- lib/Model/VersionFileHashes.php | 20 +- lib/ObjectSerializer.php | 28 +- 80 files changed, 2447 insertions(+), 3819 deletions(-) diff --git a/docs/Api/MiscApi.md b/docs/Api/MiscApi.md index 2d0bb87..4491b6a 100644 --- a/docs/Api/MiscApi.md +++ b/docs/Api/MiscApi.md @@ -1,5 +1,7 @@ # Aternos\ModrinthApi\MiscApi + + All URIs are relative to https://api.modrinth.com/v2, except if the operation defines another base path. | Method | HTTP request | Description | @@ -11,13 +13,13 @@ All URIs are relative to https://api.modrinth.com/v2, except if the operation de ## `forgeUpdates()` ```php -forgeUpdates($id_slug): \Aternos\ModrinthApi\Model\ForgeUpdates +forgeUpdates($id_slug, $neoforge): \Aternos\ModrinthApi\Model\ForgeUpdates ``` ### URI(s): - https://api.modrinth.com Production server- https://staging-api.modrinth.com Staging server Forge Updates JSON file -If you're a Forge mod developer, your Modrinth mods have an automatically generated `updates.json` using the [Forge Update Checker](https://docs.minecraftforge.net/en/latest/misc/updatechecker/). The only setup is to insert the URL into the `[[mods]]` section of your `mods.toml` file as such: ```toml [[mods]] # the other stuff here - ID, version, display name, etc. updateJSONURL = \"https://api.modrinth.com/updates/{slug|ID}/forge_updates.json\" ``` Replace `{slug|id}` with the slug or ID of your project. Modrinth will handle the rest! When you update your mod, Forge will notify your users that their copy of your mod is out of date. Make sure that the version format you use for your Modrinth releases is the same as the version format you use in your `mods.toml`. If you use a format such as `1.2.3-forge` or `1.2.3+1.19` with your Modrinth releases but your `mods.toml` only has `1.2.3`, the update checker may not function properly. +If you're a Forge mod developer, your Modrinth mods have an automatically generated `updates.json` using the [Forge Update Checker](https://docs.minecraftforge.net/en/latest/misc/updatechecker/). The only setup is to insert the URL into the `[[mods]]` section of your `mods.toml` file as such: ```toml [[mods]] # the other stuff here - ID, version, display name, etc. updateJSONURL = \"https://api.modrinth.com/updates/{slug|ID}/forge_updates.json\" ``` Replace `{slug|id}` with the slug or ID of your project. Modrinth will handle the rest! When you update your mod, Forge will notify your users that their copy of your mod is out of date. Make sure that the version format you use for your Modrinth releases is the same as the version format you use in your `mods.toml`. If you use a format such as `1.2.3-forge` or `1.2.3+1.19` with your Modrinth releases but your `mods.toml` only has `1.2.3`, the update checker may not function properly. If you're using NeoForge, NeoForge versions will, by default, not appear in the default URL. You will need to add `?neoforge=only` to show your NeoForge-only versions, or `?neoforge=include` for both. ```toml [[mods]] # the other stuff here - ID, version, display name, etc. updateJSONURL = \"https://api.modrinth.com/updates/{slug|ID}/forge_updates.json?neoforge=only\" ``` ### Example @@ -33,13 +35,14 @@ $apiInstance = new Aternos\ModrinthApi\Api\MiscApi( new GuzzleHttp\Client() ); $id_slug = ["AABBCCDD","my_project"]; // string | The ID or slug of the project +$neoforge = include; // string | Whether to include NeoForge versions. Can be `only` (NeoForge-only versions), `include` (both Forge and NeoForge versions), or omitted (Forge-only versions). $hostIndex = 0; $variables = [ ]; try { - $result = $apiInstance->forgeUpdates($id_slug, $hostIndex, $variables); + $result = $apiInstance->forgeUpdates($id_slug, $neoforge, $hostIndex, $variables); print_r($result); } catch (Exception $e) { echo 'Exception when calling MiscApi->forgeUpdates: ', $e->getMessage(), PHP_EOL; @@ -51,6 +54,7 @@ try { | Name | Type | Description | Notes | | ------------- | ------------- | ------------- | ------------- | | **id_slug** | **string**| The ID or slug of the project | | +| **neoforge** | **string**| Whether to include NeoForge versions. Can be `only` (NeoForge-only versions), `include` (both Forge and NeoForge versions), or omitted (Forge-only versions). | [optional] | | hostIndex | null|int | Host index. Defaults to null. If null, then the library will use $this->hostIndex instead | [optional] | | variables | array | Associative array of variables to pass to the host. Defaults to empty array. | [optional] | diff --git a/docs/Api/NotificationsApi.md b/docs/Api/NotificationsApi.md index 02309ff..4674ff4 100644 --- a/docs/Api/NotificationsApi.md +++ b/docs/Api/NotificationsApi.md @@ -1,5 +1,7 @@ # Aternos\ModrinthApi\NotificationsApi +Notifications are sent to users for various reasons, including for project updates, team invites, and moderation purposes. + All URIs are relative to https://api.modrinth.com/v2, except if the operation defines another base path. | Method | HTTP request | Description | diff --git a/docs/Api/ProjectsApi.md b/docs/Api/ProjectsApi.md index 19f9b54..7bed472 100644 --- a/docs/Api/ProjectsApi.md +++ b/docs/Api/ProjectsApi.md @@ -1,5 +1,7 @@ # Aternos\ModrinthApi\ProjectsApi +Projects are what Modrinth is centered around, be it mods, modpacks, resource packs, etc. + All URIs are relative to https://api.modrinth.com/v2, except if the operation defines another base path. | Method | HTTP request | Description | @@ -1006,7 +1008,7 @@ $apiInstance = new Aternos\ModrinthApi\Api\ProjectsApi( new GuzzleHttp\Client() ); $query = gravestones; // string | The query to search for -$facets = [["categories:forge"],["versions:1.17.1"],["project_type:mod"],["license:mit"]]; // string | Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` - `modified_timestamp` In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. +$facets = [["categories:forge"],["versions:1.17.1"],["project_type:mod"],["license:mit"]]; // string | Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` (uses Unix timestamp) - `modified_timestamp` (uses Unix timestamp) - `date_created` (uses ISO-8601 timestamp) - `date_modified` (uses ISO-8601 timestamp) In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. $index = downloads; // string | The sorting method used for sorting search results $offset = 20; // int | The offset into the search. Skips this number of results $limit = 20; // int | The number of results returned by the search @@ -1024,7 +1026,7 @@ try { | Name | Type | Description | Notes | | ------------- | ------------- | ------------- | ------------- | | **query** | **string**| The query to search for | [optional] | -| **facets** | **string**| Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` - `modified_timestamp` In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. | [optional] | +| **facets** | **string**| Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` (uses Unix timestamp) - `modified_timestamp` (uses Unix timestamp) - `date_created` (uses ISO-8601 timestamp) - `date_modified` (uses ISO-8601 timestamp) In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. | [optional] | | **index** | **string**| The sorting method used for sorting search results | [optional] [default to 'relevance'] | | **offset** | **int**| The offset into the search. Skips this number of results | [optional] [default to 0] | | **limit** | **int**| The number of results returned by the search | [optional] [default to 10] | diff --git a/docs/Api/TagsApi.md b/docs/Api/TagsApi.md index 907d8a5..cfc0b2e 100644 --- a/docs/Api/TagsApi.md +++ b/docs/Api/TagsApi.md @@ -1,5 +1,7 @@ # Aternos\ModrinthApi\TagsApi +Tags are common and reusable lists of metadata types such as categories or versions. Some can be applied to projects and/or versions. + All URIs are relative to https://api.modrinth.com/v2, except if the operation defines another base path. | Method | HTTP request | Description | diff --git a/docs/Api/TeamsApi.md b/docs/Api/TeamsApi.md index bda115b..f686b76 100644 --- a/docs/Api/TeamsApi.md +++ b/docs/Api/TeamsApi.md @@ -1,5 +1,7 @@ # Aternos\ModrinthApi\TeamsApi +Through teams, user permissions limit how team members can modify projects. + All URIs are relative to https://api.modrinth.com/v2, except if the operation defines another base path. | Method | HTTP request | Description | diff --git a/docs/Api/ThreadsApi.md b/docs/Api/ThreadsApi.md index 55a9faa..320241f 100644 --- a/docs/Api/ThreadsApi.md +++ b/docs/Api/ThreadsApi.md @@ -1,5 +1,7 @@ # Aternos\ModrinthApi\ThreadsApi +Threads are a way of communicating between users and moderators, for the purposes of project reviews and reports. + All URIs are relative to https://api.modrinth.com/v2, except if the operation defines another base path. | Method | HTTP request | Description | diff --git a/docs/Api/UsersApi.md b/docs/Api/UsersApi.md index 563deef..d068bbd 100644 --- a/docs/Api/UsersApi.md +++ b/docs/Api/UsersApi.md @@ -1,10 +1,13 @@ # Aternos\ModrinthApi\UsersApi +Users can create projects, join teams, access notifications, manage settings, and follow projects. Admins and moderators have more advanced permissions such as reviewing new projects. + All URIs are relative to https://api.modrinth.com/v2, except if the operation defines another base path. | Method | HTTP request | Description | | ------------- | ------------- | ------------- | | [**changeUserIcon()**](UsersApi.md#changeUserIcon) | **PATCH** /user/{id|username}/icon | Change user's avatar | +| [**deleteUserIcon()**](UsersApi.md#deleteUserIcon) | **DELETE** /user/{id|username}/icon | Remove user's avatar | | [**getFollowedProjects()**](UsersApi.md#getFollowedProjects) | **GET** /user/{id|username}/follows | Get user's followed projects | | [**getPayoutHistory()**](UsersApi.md#getPayoutHistory) | **GET** /user/{id|username}/payouts | Get user's payout history | | [**getUser()**](UsersApi.md#getUser) | **GET** /user/{id|username} | Get a user | @@ -78,6 +81,65 @@ void (empty response body) [[Back to Model list]](../../README.md#models) [[Back to README]](../../README.md) +## `deleteUserIcon()` + +```php +deleteUserIcon($id_username) +``` + +Remove user's avatar + +### Example + +```php +setApiKey('Authorization', 'YOUR_API_KEY'); +// Uncomment below to setup prefix (e.g. Bearer) for API key, if needed +// $config = Aternos\ModrinthApi\Configuration::getDefaultConfiguration()->setApiKeyPrefix('Authorization', 'Bearer'); + + +$apiInstance = new Aternos\ModrinthApi\Api\UsersApi( + // If you want use custom http client, pass your client which implements `GuzzleHttp\ClientInterface`. + // This is optional, `GuzzleHttp\Client` will be used as default. + new GuzzleHttp\Client(), + $config +); +$id_username = ["EEFFGGHH","my_user"]; // string | The ID or username of the user + +try { + $apiInstance->deleteUserIcon($id_username); +} catch (Exception $e) { + echo 'Exception when calling UsersApi->deleteUserIcon: ', $e->getMessage(), PHP_EOL; +} +``` + +### Parameters + +| Name | Type | Description | Notes | +| ------------- | ------------- | ------------- | ------------- | +| **id_username** | **string**| The ID or username of the user | | + +### Return type + +void (empty response body) + +### Authorization + +[TokenAuth](../../README.md#TokenAuth) + +### HTTP request headers + +- **Content-Type**: Not defined +- **Accept**: `application/json` + +[[Back to top]](#) [[Back to API list]](../../README.md#endpoints) +[[Back to Model list]](../../README.md#models) +[[Back to README]](../../README.md) + ## `getFollowedProjects()` ```php diff --git a/docs/Api/VersionFilesApi.md b/docs/Api/VersionFilesApi.md index 32e31b9..4f63db0 100644 --- a/docs/Api/VersionFilesApi.md +++ b/docs/Api/VersionFilesApi.md @@ -1,5 +1,7 @@ # Aternos\ModrinthApi\VersionFilesApi + + All URIs are relative to https://api.modrinth.com/v2, except if the operation defines another base path. | Method | HTTP request | Description | diff --git a/docs/Api/VersionsApi.md b/docs/Api/VersionsApi.md index 18a36c4..af2e6c2 100644 --- a/docs/Api/VersionsApi.md +++ b/docs/Api/VersionsApi.md @@ -1,5 +1,7 @@ # Aternos\ModrinthApi\VersionsApi +Versions contain download links to files with additional metadata. + All URIs are relative to https://api.modrinth.com/v2, except if the operation defines another base path. | Method | HTTP request | Description | diff --git a/docs/Model/Statistics.md b/docs/Model/Statistics.md index 5290606..497638c 100644 --- a/docs/Model/Statistics.md +++ b/docs/Model/Statistics.md @@ -5,7 +5,7 @@ Name | Type | Description | Notes ------------ | ------------- | ------------- | ------------- **projects** | **int** | Number of projects on Modrinth | [optional] -**versions** | **int** | Number of projects on Modrinth | [optional] +**versions** | **int** | Number of versions on Modrinth | [optional] **files** | **int** | Number of version files on Modrinth | [optional] **authors** | **int** | Number of authors (users with projects) on Modrinth | [optional] diff --git a/lib/Api/MiscApi.php b/lib/Api/MiscApi.php index f75bd34..d2c5219 100644 --- a/lib/Api/MiscApi.php +++ b/lib/Api/MiscApi.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -35,8 +35,11 @@ use GuzzleHttp\Psr7\MultipartStream; use GuzzleHttp\Psr7\Request; use GuzzleHttp\RequestOptions; +use Psr\Http\Message\RequestInterface; +use Psr\Http\Message\ResponseInterface; use Aternos\ModrinthApi\ApiException; use Aternos\ModrinthApi\Configuration; +use Aternos\ModrinthApi\FormDataProcessor; use Aternos\ModrinthApi\HeaderSelector; use Aternos\ModrinthApi\ObjectSerializer; @@ -137,6 +140,7 @@ public function getConfig() * URL: https://staging-api.modrinth.com * * @param string $id_slug The ID or slug of the project (required) + * @param string|null $neoforge Whether to include NeoForge versions. Can be `only` (NeoForge-only versions), `include` (both Forge and NeoForge versions), or omitted (Forge-only versions). (optional) * @param null|int $hostIndex Host index. Defaults to null. If null, then the library will use $this->hostIndex instead * @param array $variables Associative array of variables to pass to the host. Defaults to empty array. * @param string $contentType The value for the Content-Type header. Check self::contentTypes['forgeUpdates'] to see the possible values for this operation @@ -145,9 +149,9 @@ public function getConfig() * @throws \InvalidArgumentException * @return \Aternos\ModrinthApi\Model\ForgeUpdates|\Aternos\ModrinthApi\Model\InvalidInputError */ - public function forgeUpdates($id_slug, ?int $hostIndex = null, array $variables = [], string $contentType = self::contentTypes['forgeUpdates'][0]) + public function forgeUpdates($id_slug, $neoforge = null, ?int $hostIndex = null, array $variables = [], string $contentType = self::contentTypes['forgeUpdates'][0]) { - list($response) = $this->forgeUpdatesWithHttpInfo($id_slug, $hostIndex, $variables, $contentType); + list($response) = $this->forgeUpdatesWithHttpInfo($id_slug, $neoforge, $hostIndex, $variables, $contentType); return $response; } @@ -162,6 +166,7 @@ public function forgeUpdates($id_slug, ?int $hostIndex = null, array $variables * URL: https://staging-api.modrinth.com * * @param string $id_slug The ID or slug of the project (required) + * @param string|null $neoforge Whether to include NeoForge versions. Can be `only` (NeoForge-only versions), `include` (both Forge and NeoForge versions), or omitted (Forge-only versions). (optional) * @param null|int $hostIndex Host index. Defaults to null. If null, then the library will use $this->hostIndex instead * @param array $variables Associative array of variables to pass to the host. Defaults to empty array. * @param string $contentType The value for the Content-Type header. Check self::contentTypes['forgeUpdates'] to see the possible values for this operation @@ -170,9 +175,9 @@ public function forgeUpdates($id_slug, ?int $hostIndex = null, array $variables * @throws \InvalidArgumentException * @return array of \Aternos\ModrinthApi\Model\ForgeUpdates|\Aternos\ModrinthApi\Model\InvalidInputError, HTTP status code, HTTP response headers (array of strings) */ - public function forgeUpdatesWithHttpInfo($id_slug, ?int $hostIndex = null, array $variables = [], string $contentType = self::contentTypes['forgeUpdates'][0]) + public function forgeUpdatesWithHttpInfo($id_slug, $neoforge = null, ?int $hostIndex = null, array $variables = [], string $contentType = self::contentTypes['forgeUpdates'][0]) { - $request = $this->forgeUpdatesRequest($id_slug, $hostIndex, $variables, $contentType); + $request = $this->forgeUpdatesRequest($id_slug, $neoforge, $hostIndex, $variables, $contentType); try { $options = $this->createHttpClientOption(); @@ -199,61 +204,21 @@ public function forgeUpdatesWithHttpInfo($id_slug, ?int $hostIndex = null, array switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\ForgeUpdates' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\ForgeUpdates' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\ForgeUpdates', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\ForgeUpdates', + $request, + $response, + ); case 400: - if ('\Aternos\ModrinthApi\Model\InvalidInputError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\InvalidInputError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\InvalidInputError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\InvalidInputError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -267,34 +232,11 @@ public function forgeUpdatesWithHttpInfo($id_slug, ?int $hostIndex = null, array ); } - $returnType = '\Aternos\ModrinthApi\Model\ForgeUpdates'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\ForgeUpdates', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -304,7 +246,7 @@ public function forgeUpdatesWithHttpInfo($id_slug, ?int $hostIndex = null, array $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 400: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -312,8 +254,10 @@ public function forgeUpdatesWithHttpInfo($id_slug, ?int $hostIndex = null, array $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -329,6 +273,7 @@ public function forgeUpdatesWithHttpInfo($id_slug, ?int $hostIndex = null, array * URL: https://staging-api.modrinth.com * * @param string $id_slug The ID or slug of the project (required) + * @param string|null $neoforge Whether to include NeoForge versions. Can be `only` (NeoForge-only versions), `include` (both Forge and NeoForge versions), or omitted (Forge-only versions). (optional) * @param null|int $hostIndex Host index. Defaults to null. If null, then the library will use $this->hostIndex instead * @param array $variables Associative array of variables to pass to the host. Defaults to empty array. * @param string $contentType The value for the Content-Type header. Check self::contentTypes['forgeUpdates'] to see the possible values for this operation @@ -336,9 +281,9 @@ public function forgeUpdatesWithHttpInfo($id_slug, ?int $hostIndex = null, array * @throws \InvalidArgumentException * @return \GuzzleHttp\Promise\PromiseInterface */ - public function forgeUpdatesAsync($id_slug, ?int $hostIndex = null, array $variables = [], string $contentType = self::contentTypes['forgeUpdates'][0]) + public function forgeUpdatesAsync($id_slug, $neoforge = null, ?int $hostIndex = null, array $variables = [], string $contentType = self::contentTypes['forgeUpdates'][0]) { - return $this->forgeUpdatesAsyncWithHttpInfo($id_slug, $hostIndex, $variables, $contentType) + return $this->forgeUpdatesAsyncWithHttpInfo($id_slug, $neoforge, $hostIndex, $variables, $contentType) ->then( function ($response) { return $response[0]; @@ -357,6 +302,7 @@ function ($response) { * URL: https://staging-api.modrinth.com * * @param string $id_slug The ID or slug of the project (required) + * @param string|null $neoforge Whether to include NeoForge versions. Can be `only` (NeoForge-only versions), `include` (both Forge and NeoForge versions), or omitted (Forge-only versions). (optional) * @param null|int $hostIndex Host index. Defaults to null. If null, then the library will use $this->hostIndex instead * @param array $variables Associative array of variables to pass to the host. Defaults to empty array. * @param string $contentType The value for the Content-Type header. Check self::contentTypes['forgeUpdates'] to see the possible values for this operation @@ -364,10 +310,10 @@ function ($response) { * @throws \InvalidArgumentException * @return \GuzzleHttp\Promise\PromiseInterface */ - public function forgeUpdatesAsyncWithHttpInfo($id_slug, ?int $hostIndex = null, array $variables = [], string $contentType = self::contentTypes['forgeUpdates'][0]) + public function forgeUpdatesAsyncWithHttpInfo($id_slug, $neoforge = null, ?int $hostIndex = null, array $variables = [], string $contentType = self::contentTypes['forgeUpdates'][0]) { $returnType = '\Aternos\ModrinthApi\Model\ForgeUpdates'; - $request = $this->forgeUpdatesRequest($id_slug, $hostIndex, $variables, $contentType); + $request = $this->forgeUpdatesRequest($id_slug, $neoforge, $hostIndex, $variables, $contentType); return $this->client ->sendAsync($request, $this->createHttpClientOption()) @@ -414,6 +360,7 @@ function ($exception) { * URL: https://staging-api.modrinth.com * * @param string $id_slug The ID or slug of the project (required) + * @param string|null $neoforge Whether to include NeoForge versions. Can be `only` (NeoForge-only versions), `include` (both Forge and NeoForge versions), or omitted (Forge-only versions). (optional) * @param null|int $hostIndex Host index. Defaults to null. If null, then the library will use $this->hostIndex instead * @param array $variables Associative array of variables to pass to the host. Defaults to empty array. * @param string $contentType The value for the Content-Type header. Check self::contentTypes['forgeUpdates'] to see the possible values for this operation @@ -421,7 +368,7 @@ function ($exception) { * @throws \InvalidArgumentException * @return \GuzzleHttp\Psr7\Request */ - public function forgeUpdatesRequest($id_slug, ?int $hostIndex = null, array $variables = [], string $contentType = self::contentTypes['forgeUpdates'][0]) + public function forgeUpdatesRequest($id_slug, $neoforge = null, ?int $hostIndex = null, array $variables = [], string $contentType = self::contentTypes['forgeUpdates'][0]) { // verify the required parameter 'id_slug' is set @@ -432,6 +379,7 @@ public function forgeUpdatesRequest($id_slug, ?int $hostIndex = null, array $var } + $resourcePath = '/updates/{id|slug}/forge_updates.json'; $formParams = []; $queryParams = []; @@ -439,6 +387,15 @@ public function forgeUpdatesRequest($id_slug, ?int $hostIndex = null, array $var $httpBody = ''; $multipart = false; + // query params + $queryParams = array_merge($queryParams, ObjectSerializer::toQueryValue( + $neoforge, + 'neoforge', // param base name + 'string', // openApiType + 'form', // style + true, // explode + false // required + ) ?? []); // path params @@ -590,34 +547,15 @@ public function statisticsWithHttpInfo(string $contentType = self::contentTypes[ switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Statistics' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Statistics' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Statistics', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Statistics', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -631,34 +569,11 @@ public function statisticsWithHttpInfo(string $contentType = self::contentTypes[ ); } - $returnType = '\Aternos\ModrinthApi\Model\Statistics'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Statistics', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -668,8 +583,10 @@ public function statisticsWithHttpInfo(string $contentType = self::contentTypes[ $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -837,6 +754,57 @@ protected function createHttpClientOption() } } + if ($this->config->getCertFile()) { + $options[RequestOptions::CERT] = $this->config->getCertFile(); + } + + if ($this->config->getKeyFile()) { + $options[RequestOptions::SSL_KEY] = $this->config->getKeyFile(); + } + return $options; } + + private function handleResponseWithDataType( + string $dataType, + RequestInterface $request, + ResponseInterface $response + ): array { + if ($dataType === '\SplFileObject') { + $content = $response->getBody(); //stream goes to serializer + } else { + $content = (string) $response->getBody(); + if ($dataType !== 'string') { + try { + $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); + } catch (\JsonException $exception) { + throw new ApiException( + sprintf( + 'Error JSON decoding server response (%s)', + $request->getUri() + ), + $response->getStatusCode(), + $response->getHeaders(), + $content + ); + } + } + } + + return [ + ObjectSerializer::deserialize($content, $dataType, []), + $response->getStatusCode(), + $response->getHeaders() + ]; + } + + private function responseWithinRangeCode( + string $rangeCode, + int $statusCode + ): bool { + $left = (int) ($rangeCode[0].'00'); + $right = (int) ($rangeCode[0].'99'); + + return $statusCode >= $left && $statusCode <= $right; + } } diff --git a/lib/Api/NotificationsApi.php b/lib/Api/NotificationsApi.php index b26a847..91d5d93 100644 --- a/lib/Api/NotificationsApi.php +++ b/lib/Api/NotificationsApi.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -35,8 +35,11 @@ use GuzzleHttp\Psr7\MultipartStream; use GuzzleHttp\Psr7\Request; use GuzzleHttp\RequestOptions; +use Psr\Http\Message\RequestInterface; +use Psr\Http\Message\ResponseInterface; use Aternos\ModrinthApi\ApiException; use Aternos\ModrinthApi\Configuration; +use Aternos\ModrinthApi\FormDataProcessor; use Aternos\ModrinthApi\HeaderSelector; use Aternos\ModrinthApi\ObjectSerializer; @@ -198,7 +201,6 @@ public function deleteNotificationWithHttpInfo($id, string $contentType = self:: return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -208,8 +210,10 @@ public function deleteNotificationWithHttpInfo($id, string $contentType = self:: $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -428,7 +432,6 @@ public function deleteNotificationsWithHttpInfo($ids, string $contentType = self return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -438,8 +441,10 @@ public function deleteNotificationsWithHttpInfo($ids, string $contentType = self $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -661,61 +666,21 @@ public function getNotificationWithHttpInfo($id, string $contentType = self::con switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Notification' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Notification' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Notification', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Notification', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -729,34 +694,11 @@ public function getNotificationWithHttpInfo($id, string $contentType = self::con ); } - $returnType = '\Aternos\ModrinthApi\Model\Notification'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Notification', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -766,7 +708,7 @@ public function getNotificationWithHttpInfo($id, string $contentType = self::con $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -774,8 +716,10 @@ public function getNotificationWithHttpInfo($id, string $contentType = self::con $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1009,61 +953,21 @@ public function getNotificationsWithHttpInfo($ids, string $contentType = self::c switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Notification[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Notification[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Notification[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Notification[]', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1077,34 +981,11 @@ public function getNotificationsWithHttpInfo($ids, string $contentType = self::c ); } - $returnType = '\Aternos\ModrinthApi\Model\Notification[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Notification[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1114,7 +995,7 @@ public function getNotificationsWithHttpInfo($ids, string $contentType = self::c $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -1122,8 +1003,10 @@ public function getNotificationsWithHttpInfo($ids, string $contentType = self::c $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1358,61 +1241,21 @@ public function getUserNotificationsWithHttpInfo($id_username, string $contentTy switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Notification[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Notification[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Notification[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Notification[]', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1426,34 +1269,11 @@ public function getUserNotificationsWithHttpInfo($id_username, string $contentTy ); } - $returnType = '\Aternos\ModrinthApi\Model\Notification[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Notification[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1463,7 +1283,7 @@ public function getUserNotificationsWithHttpInfo($id_username, string $contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -1471,8 +1291,10 @@ public function getUserNotificationsWithHttpInfo($id_username, string $contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1704,7 +1526,6 @@ public function readNotificationWithHttpInfo($id, string $contentType = self::co return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -1714,8 +1535,10 @@ public function readNotificationWithHttpInfo($id, string $contentType = self::co $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1934,7 +1757,6 @@ public function readNotificationsWithHttpInfo($ids, string $contentType = self:: return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -1944,8 +1766,10 @@ public function readNotificationsWithHttpInfo($ids, string $contentType = self:: $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2124,6 +1948,57 @@ protected function createHttpClientOption() } } + if ($this->config->getCertFile()) { + $options[RequestOptions::CERT] = $this->config->getCertFile(); + } + + if ($this->config->getKeyFile()) { + $options[RequestOptions::SSL_KEY] = $this->config->getKeyFile(); + } + return $options; } + + private function handleResponseWithDataType( + string $dataType, + RequestInterface $request, + ResponseInterface $response + ): array { + if ($dataType === '\SplFileObject') { + $content = $response->getBody(); //stream goes to serializer + } else { + $content = (string) $response->getBody(); + if ($dataType !== 'string') { + try { + $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); + } catch (\JsonException $exception) { + throw new ApiException( + sprintf( + 'Error JSON decoding server response (%s)', + $request->getUri() + ), + $response->getStatusCode(), + $response->getHeaders(), + $content + ); + } + } + } + + return [ + ObjectSerializer::deserialize($content, $dataType, []), + $response->getStatusCode(), + $response->getHeaders() + ]; + } + + private function responseWithinRangeCode( + string $rangeCode, + int $statusCode + ): bool { + $left = (int) ($rangeCode[0].'00'); + $right = (int) ($rangeCode[0].'99'); + + return $statusCode >= $left && $statusCode <= $right; + } } diff --git a/lib/Api/ProjectsApi.php b/lib/Api/ProjectsApi.php index 12a0297..80f4d28 100644 --- a/lib/Api/ProjectsApi.php +++ b/lib/Api/ProjectsApi.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -35,8 +35,11 @@ use GuzzleHttp\Psr7\MultipartStream; use GuzzleHttp\Psr7\Request; use GuzzleHttp\RequestOptions; +use Psr\Http\Message\RequestInterface; +use Psr\Http\Message\ResponseInterface; use Aternos\ModrinthApi\ApiException; use Aternos\ModrinthApi\Configuration; +use Aternos\ModrinthApi\FormDataProcessor; use Aternos\ModrinthApi\HeaderSelector; use Aternos\ModrinthApi\ObjectSerializer; @@ -257,7 +260,6 @@ public function addGalleryImageWithHttpInfo($id_slug, $ext, $featured, $title = return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -267,7 +269,7 @@ public function addGalleryImageWithHttpInfo($id_slug, $ext, $featured, $title = $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -275,8 +277,10 @@ public function addGalleryImageWithHttpInfo($id_slug, $ext, $featured, $title = $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -587,7 +591,6 @@ public function changeProjectIconWithHttpInfo($id_slug, $ext, $body = null, stri return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -597,8 +600,10 @@ public function changeProjectIconWithHttpInfo($id_slug, $ext, $body = null, stri $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -849,34 +854,15 @@ public function checkProjectValidityWithHttpInfo($id_slug, string $contentType = switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\ProjectIdentifier' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\ProjectIdentifier' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\ProjectIdentifier', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\ProjectIdentifier', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -890,34 +876,11 @@ public function checkProjectValidityWithHttpInfo($id_slug, string $contentType = ); } - $returnType = '\Aternos\ModrinthApi\Model\ProjectIdentifier'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\ProjectIdentifier', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -927,8 +890,10 @@ public function checkProjectValidityWithHttpInfo($id_slug, string $contentType = $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1159,88 +1124,27 @@ public function createProjectWithHttpInfo($data, $icon = null, string $contentTy switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Project' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Project' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Project', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project', + $request, + $response, + ); case 400: - if ('\Aternos\ModrinthApi\Model\InvalidInputError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\InvalidInputError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\InvalidInputError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\InvalidInputError', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1254,34 +1158,11 @@ public function createProjectWithHttpInfo($data, $icon = null, string $contentTy ); } - $returnType = '\Aternos\ModrinthApi\Model\Project'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1291,7 +1172,7 @@ public function createProjectWithHttpInfo($data, $icon = null, string $contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 400: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -1299,7 +1180,7 @@ public function createProjectWithHttpInfo($data, $icon = null, string $contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -1307,8 +1188,10 @@ public function createProjectWithHttpInfo($data, $icon = null, string $contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1421,21 +1304,15 @@ public function createProjectRequest($data, $icon = null, string $contentType = // form params - if ($data !== null) { - $formParams['data'] = ObjectSerializer::toFormValue($data); - } - // form params - if ($icon !== null) { - $multipart = true; - $formParams['icon'] = []; - $paramFiles = is_array($icon) ? $icon : [$icon]; - foreach ($paramFiles as $paramFile) { - $formParams['icon'][] = \GuzzleHttp\Psr7\Utils::tryFopen( - ObjectSerializer::toFormValue($paramFile), - 'rb' - ); - } - } + $formDataProcessor = new FormDataProcessor(); + + $formData = $formDataProcessor->prepare([ + 'data' => $data, + 'icon' => $icon, + ]); + + $formParams = $formDataProcessor->flatten($formData); + $multipart = $formDataProcessor->has_file; $multipart = true; $headers = $this->headerSelector->selectHeaders( @@ -1555,7 +1432,6 @@ public function deleteGalleryImageWithHttpInfo($id_slug, $url, string $contentTy return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -1565,7 +1441,7 @@ public function deleteGalleryImageWithHttpInfo($id_slug, $url, string $contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -1573,8 +1449,10 @@ public function deleteGalleryImageWithHttpInfo($id_slug, $url, string $contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1812,7 +1690,6 @@ public function deleteProjectWithHttpInfo($id_slug, string $contentType = self:: return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -1822,7 +1699,7 @@ public function deleteProjectWithHttpInfo($id_slug, string $contentType = self:: $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -1830,8 +1707,10 @@ public function deleteProjectWithHttpInfo($id_slug, string $contentType = self:: $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2050,7 +1929,6 @@ public function deleteProjectIconWithHttpInfo($id_slug, string $contentType = se return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -2060,7 +1938,7 @@ public function deleteProjectIconWithHttpInfo($id_slug, string $contentType = se $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -2068,8 +1946,10 @@ public function deleteProjectIconWithHttpInfo($id_slug, string $contentType = se $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2288,7 +2168,6 @@ public function followProjectWithHttpInfo($id_slug, string $contentType = self:: return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -2298,7 +2177,7 @@ public function followProjectWithHttpInfo($id_slug, string $contentType = self:: $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -2306,8 +2185,10 @@ public function followProjectWithHttpInfo($id_slug, string $contentType = self:: $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2528,34 +2409,15 @@ public function getDependenciesWithHttpInfo($id_slug, string $contentType = self switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\ProjectDependencyList' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\ProjectDependencyList' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\ProjectDependencyList', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\ProjectDependencyList', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -2569,34 +2431,11 @@ public function getDependenciesWithHttpInfo($id_slug, string $contentType = self ); } - $returnType = '\Aternos\ModrinthApi\Model\ProjectDependencyList'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\ProjectDependencyList', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -2606,8 +2445,10 @@ public function getDependenciesWithHttpInfo($id_slug, string $contentType = self $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2836,34 +2677,15 @@ public function getProjectWithHttpInfo($id_slug, string $contentType = self::con switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Project' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Project' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Project', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -2877,34 +2699,11 @@ public function getProjectWithHttpInfo($id_slug, string $contentType = self::con ); } - $returnType = '\Aternos\ModrinthApi\Model\Project'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -2914,8 +2713,10 @@ public function getProjectWithHttpInfo($id_slug, string $contentType = self::con $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -3144,34 +2945,15 @@ public function getProjectsWithHttpInfo($ids, string $contentType = self::conten switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Project[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Project[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Project[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -3185,34 +2967,11 @@ public function getProjectsWithHttpInfo($ids, string $contentType = self::conten ); } - $returnType = '\Aternos\ModrinthApi\Model\Project[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -3222,8 +2981,10 @@ public function getProjectsWithHttpInfo($ids, string $contentType = self::conten $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -3461,7 +3222,6 @@ public function modifyGalleryImageWithHttpInfo($id_slug, $url, $featured = null, return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -3471,8 +3231,10 @@ public function modifyGalleryImageWithHttpInfo($id_slug, $url, $featured = null, $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -3764,7 +3526,6 @@ public function modifyProjectWithHttpInfo($id_slug, $editable_project = null, st return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -3774,8 +3535,10 @@ public function modifyProjectWithHttpInfo($id_slug, $editable_project = null, st $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -4007,7 +3770,6 @@ public function patchProjectsWithHttpInfo($ids, $patch_projects_body = null, str return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -4017,7 +3779,7 @@ public function patchProjectsWithHttpInfo($ids, $patch_projects_body = null, str $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -4025,8 +3787,10 @@ public function patchProjectsWithHttpInfo($ids, $patch_projects_body = null, str $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -4259,61 +4023,21 @@ public function randomProjectsWithHttpInfo($count, string $contentType = self::c switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Project[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Project[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Project[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project[]', + $request, + $response, + ); case 400: - if ('\Aternos\ModrinthApi\Model\InvalidInputError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\InvalidInputError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\InvalidInputError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\InvalidInputError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -4327,34 +4051,11 @@ public function randomProjectsWithHttpInfo($count, string $contentType = self::c ); } - $returnType = '\Aternos\ModrinthApi\Model\Project[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -4364,7 +4065,7 @@ public function randomProjectsWithHttpInfo($count, string $contentType = self::c $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 400: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -4372,8 +4073,10 @@ public function randomProjectsWithHttpInfo($count, string $contentType = self::c $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -4609,7 +4312,6 @@ public function scheduleProjectWithHttpInfo($id_slug, $schedule = null, string $ return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -4619,7 +4321,7 @@ public function scheduleProjectWithHttpInfo($id_slug, $schedule = null, string $ $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -4627,8 +4329,10 @@ public function scheduleProjectWithHttpInfo($id_slug, $schedule = null, string $ $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -4807,7 +4511,7 @@ public function scheduleProjectRequest($id_slug, $schedule = null, string $conte * Search projects * * @param string|null $query The query to search for (optional) - * @param string|null $facets Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` - `modified_timestamp` In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. (optional) + * @param string|null $facets Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` (uses Unix timestamp) - `modified_timestamp` (uses Unix timestamp) - `date_created` (uses ISO-8601 timestamp) - `date_modified` (uses ISO-8601 timestamp) In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. (optional) * @param string|null $index The sorting method used for sorting search results (optional, default to 'relevance') * @param int|null $offset The offset into the search. Skips this number of results (optional, default to 0) * @param int|null $limit The number of results returned by the search (optional, default to 10) @@ -4829,7 +4533,7 @@ public function searchProjects($query = null, $facets = null, $index = 'relevanc * Search projects * * @param string|null $query The query to search for (optional) - * @param string|null $facets Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` - `modified_timestamp` In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. (optional) + * @param string|null $facets Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` (uses Unix timestamp) - `modified_timestamp` (uses Unix timestamp) - `date_created` (uses ISO-8601 timestamp) - `date_modified` (uses ISO-8601 timestamp) In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. (optional) * @param string|null $index The sorting method used for sorting search results (optional, default to 'relevance') * @param int|null $offset The offset into the search. Skips this number of results (optional, default to 0) * @param int|null $limit The number of results returned by the search (optional, default to 10) @@ -4868,61 +4572,21 @@ public function searchProjectsWithHttpInfo($query = null, $facets = null, $index switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\SearchResults' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\SearchResults' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\SearchResults', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\SearchResults', + $request, + $response, + ); case 400: - if ('\Aternos\ModrinthApi\Model\InvalidInputError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\InvalidInputError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\InvalidInputError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\InvalidInputError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -4936,34 +4600,11 @@ public function searchProjectsWithHttpInfo($query = null, $facets = null, $index ); } - $returnType = '\Aternos\ModrinthApi\Model\SearchResults'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\SearchResults', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -4973,7 +4614,7 @@ public function searchProjectsWithHttpInfo($query = null, $facets = null, $index $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 400: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -4981,8 +4622,10 @@ public function searchProjectsWithHttpInfo($query = null, $facets = null, $index $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -4993,7 +4636,7 @@ public function searchProjectsWithHttpInfo($query = null, $facets = null, $index * Search projects * * @param string|null $query The query to search for (optional) - * @param string|null $facets Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` - `modified_timestamp` In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. (optional) + * @param string|null $facets Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` (uses Unix timestamp) - `modified_timestamp` (uses Unix timestamp) - `date_created` (uses ISO-8601 timestamp) - `date_modified` (uses ISO-8601 timestamp) In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. (optional) * @param string|null $index The sorting method used for sorting search results (optional, default to 'relevance') * @param int|null $offset The offset into the search. Skips this number of results (optional, default to 0) * @param int|null $limit The number of results returned by the search (optional, default to 10) @@ -5018,7 +4661,7 @@ function ($response) { * Search projects * * @param string|null $query The query to search for (optional) - * @param string|null $facets Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` - `modified_timestamp` In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. (optional) + * @param string|null $facets Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` (uses Unix timestamp) - `modified_timestamp` (uses Unix timestamp) - `date_created` (uses ISO-8601 timestamp) - `date_modified` (uses ISO-8601 timestamp) In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. (optional) * @param string|null $index The sorting method used for sorting search results (optional, default to 'relevance') * @param int|null $offset The offset into the search. Skips this number of results (optional, default to 0) * @param int|null $limit The number of results returned by the search (optional, default to 10) @@ -5072,7 +4715,7 @@ function ($exception) { * Create request for operation 'searchProjects' * * @param string|null $query The query to search for (optional) - * @param string|null $facets Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` - `modified_timestamp` In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. (optional) + * @param string|null $facets Facets are an essential concept for understanding how to filter out results. These are the most commonly used facet types: - `project_type` - `categories` (loaders are lumped in with categories in search) - `versions` - `client_side` - `server_side` - `open_source` Several others are also available for use, though these should not be used outside very specific use cases. - `title` - `author` - `follows` - `project_id` - `license` - `downloads` - `color` - `created_timestamp` (uses Unix timestamp) - `modified_timestamp` (uses Unix timestamp) - `date_created` (uses ISO-8601 timestamp) - `date_modified` (uses ISO-8601 timestamp) In order to then use these facets, you need a value to filter by, as well as an operation to perform on this value. The most common operation is `:` (same as `=`), though you can also use `!=`, `>=`, `>`, `<=`, and `<`. Join together the type, operation, and value, and you've got your string. ``` {type} {operation} {value} ``` Examples: ``` categories = adventure versions != 1.20.1 downloads <= 100 ``` You then join these strings together in arrays to signal `AND` and `OR` operators. ##### OR All elements in a single array are considered to be joined by OR statements. For example, the search `[[\"versions:1.16.5\", \"versions:1.17.1\"]]` translates to `Projects that support 1.16.5 OR 1.17.1`. ##### AND Separate arrays are considered to be joined by AND statements. For example, the search `[[\"versions:1.16.5\"], [\"project_type:modpack\"]]` translates to `Projects that support 1.16.5 AND are modpacks`. (optional) * @param string|null $index The sorting method used for sorting search results (optional, default to 'relevance') * @param int|null $offset The offset into the search. Skips this number of results (optional, default to 0) * @param int|null $limit The number of results returned by the search (optional, default to 10) @@ -5262,7 +4905,6 @@ public function unfollowProjectWithHttpInfo($id_slug, string $contentType = self return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -5272,7 +4914,7 @@ public function unfollowProjectWithHttpInfo($id_slug, string $contentType = self $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -5280,8 +4922,10 @@ public function unfollowProjectWithHttpInfo($id_slug, string $contentType = self $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -5459,6 +5103,57 @@ protected function createHttpClientOption() } } + if ($this->config->getCertFile()) { + $options[RequestOptions::CERT] = $this->config->getCertFile(); + } + + if ($this->config->getKeyFile()) { + $options[RequestOptions::SSL_KEY] = $this->config->getKeyFile(); + } + return $options; } + + private function handleResponseWithDataType( + string $dataType, + RequestInterface $request, + ResponseInterface $response + ): array { + if ($dataType === '\SplFileObject') { + $content = $response->getBody(); //stream goes to serializer + } else { + $content = (string) $response->getBody(); + if ($dataType !== 'string') { + try { + $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); + } catch (\JsonException $exception) { + throw new ApiException( + sprintf( + 'Error JSON decoding server response (%s)', + $request->getUri() + ), + $response->getStatusCode(), + $response->getHeaders(), + $content + ); + } + } + } + + return [ + ObjectSerializer::deserialize($content, $dataType, []), + $response->getStatusCode(), + $response->getHeaders() + ]; + } + + private function responseWithinRangeCode( + string $rangeCode, + int $statusCode + ): bool { + $left = (int) ($rangeCode[0].'00'); + $right = (int) ($rangeCode[0].'99'); + + return $statusCode >= $left && $statusCode <= $right; + } } diff --git a/lib/Api/TagsApi.php b/lib/Api/TagsApi.php index d6c3f4e..99691fd 100644 --- a/lib/Api/TagsApi.php +++ b/lib/Api/TagsApi.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -35,8 +35,11 @@ use GuzzleHttp\Psr7\MultipartStream; use GuzzleHttp\Psr7\Request; use GuzzleHttp\RequestOptions; +use Psr\Http\Message\RequestInterface; +use Psr\Http\Message\ResponseInterface; use Aternos\ModrinthApi\ApiException; use Aternos\ModrinthApi\Configuration; +use Aternos\ModrinthApi\FormDataProcessor; use Aternos\ModrinthApi\HeaderSelector; use Aternos\ModrinthApi\ObjectSerializer; @@ -204,34 +207,15 @@ public function categoryListWithHttpInfo(string $contentType = self::contentType switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\CategoryTag[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\CategoryTag[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\CategoryTag[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\CategoryTag[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -245,34 +229,11 @@ public function categoryListWithHttpInfo(string $contentType = self::contentType ); } - $returnType = '\Aternos\ModrinthApi\Model\CategoryTag[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\CategoryTag[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -282,8 +243,10 @@ public function categoryListWithHttpInfo(string $contentType = self::contentType $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -492,34 +455,15 @@ public function donationPlatformListWithHttpInfo(string $contentType = self::con switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\DonationPlatformTag[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\DonationPlatformTag[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\DonationPlatformTag[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\DonationPlatformTag[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -533,34 +477,11 @@ public function donationPlatformListWithHttpInfo(string $contentType = self::con ); } - $returnType = '\Aternos\ModrinthApi\Model\DonationPlatformTag[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\DonationPlatformTag[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -570,8 +491,10 @@ public function donationPlatformListWithHttpInfo(string $contentType = self::con $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -782,34 +705,15 @@ public function licenseListWithHttpInfo(string $contentType = self::contentTypes switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\LicenseTag[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\LicenseTag[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\LicenseTag[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\LicenseTag[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -823,34 +727,11 @@ public function licenseListWithHttpInfo(string $contentType = self::contentTypes ); } - $returnType = '\Aternos\ModrinthApi\Model\LicenseTag[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\LicenseTag[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -860,8 +741,10 @@ public function licenseListWithHttpInfo(string $contentType = self::contentTypes $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1075,61 +958,21 @@ public function licenseTextWithHttpInfo($id, string $contentType = self::content switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\License' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\License' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\License', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\License', + $request, + $response, + ); case 400: - if ('\Aternos\ModrinthApi\Model\InvalidInputError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\InvalidInputError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\InvalidInputError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\InvalidInputError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1143,34 +986,11 @@ public function licenseTextWithHttpInfo($id, string $contentType = self::content ); } - $returnType = '\Aternos\ModrinthApi\Model\License'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\License', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1180,7 +1000,7 @@ public function licenseTextWithHttpInfo($id, string $contentType = self::content $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 400: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -1188,8 +1008,10 @@ public function licenseTextWithHttpInfo($id, string $contentType = self::content $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1416,34 +1238,15 @@ public function loaderListWithHttpInfo(string $contentType = self::contentTypes[ switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\LoaderTag[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\LoaderTag[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\LoaderTag[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\LoaderTag[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1457,34 +1260,11 @@ public function loaderListWithHttpInfo(string $contentType = self::contentTypes[ ); } - $returnType = '\Aternos\ModrinthApi\Model\LoaderTag[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\LoaderTag[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1494,8 +1274,10 @@ public function loaderListWithHttpInfo(string $contentType = self::contentTypes[ $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1704,34 +1486,15 @@ public function projectTypeListWithHttpInfo(string $contentType = self::contentT switch($statusCode) { case 200: - if ('string[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('string[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, 'string[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + 'string[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1745,34 +1508,11 @@ public function projectTypeListWithHttpInfo(string $contentType = self::contentT ); } - $returnType = 'string[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + 'string[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1782,8 +1522,10 @@ public function projectTypeListWithHttpInfo(string $contentType = self::contentT $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1992,34 +1734,15 @@ public function reportTypeListWithHttpInfo(string $contentType = self::contentTy switch($statusCode) { case 200: - if ('string[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('string[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, 'string[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + 'string[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -2033,34 +1756,11 @@ public function reportTypeListWithHttpInfo(string $contentType = self::contentTy ); } - $returnType = 'string[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + 'string[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -2070,8 +1770,10 @@ public function reportTypeListWithHttpInfo(string $contentType = self::contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2280,34 +1982,15 @@ public function sideTypeListWithHttpInfo(string $contentType = self::contentType switch($statusCode) { case 200: - if ('string[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('string[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, 'string[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + 'string[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -2321,34 +2004,11 @@ public function sideTypeListWithHttpInfo(string $contentType = self::contentType ); } - $returnType = 'string[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + 'string[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -2358,8 +2018,10 @@ public function sideTypeListWithHttpInfo(string $contentType = self::contentType $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2568,34 +2230,15 @@ public function versionListWithHttpInfo(string $contentType = self::contentTypes switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\GameVersionTag[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\GameVersionTag[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\GameVersionTag[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\GameVersionTag[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -2609,34 +2252,11 @@ public function versionListWithHttpInfo(string $contentType = self::contentTypes ); } - $returnType = '\Aternos\ModrinthApi\Model\GameVersionTag[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\GameVersionTag[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -2646,8 +2266,10 @@ public function versionListWithHttpInfo(string $contentType = self::contentTypes $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2815,6 +2437,57 @@ protected function createHttpClientOption() } } + if ($this->config->getCertFile()) { + $options[RequestOptions::CERT] = $this->config->getCertFile(); + } + + if ($this->config->getKeyFile()) { + $options[RequestOptions::SSL_KEY] = $this->config->getKeyFile(); + } + return $options; } + + private function handleResponseWithDataType( + string $dataType, + RequestInterface $request, + ResponseInterface $response + ): array { + if ($dataType === '\SplFileObject') { + $content = $response->getBody(); //stream goes to serializer + } else { + $content = (string) $response->getBody(); + if ($dataType !== 'string') { + try { + $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); + } catch (\JsonException $exception) { + throw new ApiException( + sprintf( + 'Error JSON decoding server response (%s)', + $request->getUri() + ), + $response->getStatusCode(), + $response->getHeaders(), + $content + ); + } + } + } + + return [ + ObjectSerializer::deserialize($content, $dataType, []), + $response->getStatusCode(), + $response->getHeaders() + ]; + } + + private function responseWithinRangeCode( + string $rangeCode, + int $statusCode + ): bool { + $left = (int) ($rangeCode[0].'00'); + $right = (int) ($rangeCode[0].'99'); + + return $statusCode >= $left && $statusCode <= $right; + } } diff --git a/lib/Api/TeamsApi.php b/lib/Api/TeamsApi.php index e15dfa4..0be160d 100644 --- a/lib/Api/TeamsApi.php +++ b/lib/Api/TeamsApi.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -35,8 +35,11 @@ use GuzzleHttp\Psr7\MultipartStream; use GuzzleHttp\Psr7\Request; use GuzzleHttp\RequestOptions; +use Psr\Http\Message\RequestInterface; +use Psr\Http\Message\ResponseInterface; use Aternos\ModrinthApi\ApiException; use Aternos\ModrinthApi\Configuration; +use Aternos\ModrinthApi\FormDataProcessor; use Aternos\ModrinthApi\HeaderSelector; use Aternos\ModrinthApi\ObjectSerializer; @@ -203,7 +206,6 @@ public function addTeamMemberWithHttpInfo($id, $user_identifier = null, string $ return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -213,8 +215,10 @@ public function addTeamMemberWithHttpInfo($id, $user_identifier = null, string $ $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -446,7 +450,6 @@ public function deleteTeamMemberWithHttpInfo($id, $id_username, string $contentT return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -456,8 +459,10 @@ public function deleteTeamMemberWithHttpInfo($id, $id_username, string $contentT $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -696,34 +701,15 @@ public function getProjectTeamMembersWithHttpInfo($id_slug, string $contentType switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\TeamMember[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\TeamMember[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\TeamMember[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\TeamMember[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -737,34 +723,11 @@ public function getProjectTeamMembersWithHttpInfo($id_slug, string $contentType ); } - $returnType = '\Aternos\ModrinthApi\Model\TeamMember[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\TeamMember[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -774,8 +737,10 @@ public function getProjectTeamMembersWithHttpInfo($id_slug, string $contentType $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1004,34 +969,15 @@ public function getTeamMembersWithHttpInfo($id, string $contentType = self::cont switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\TeamMember[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\TeamMember[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\TeamMember[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\TeamMember[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1045,34 +991,11 @@ public function getTeamMembersWithHttpInfo($id, string $contentType = self::cont ); } - $returnType = '\Aternos\ModrinthApi\Model\TeamMember[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\TeamMember[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1082,8 +1005,10 @@ public function getTeamMembersWithHttpInfo($id, string $contentType = self::cont $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1317,34 +1242,15 @@ public function getTeamsWithHttpInfo($ids, string $contentType = self::contentTy switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\TeamMember[][]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\TeamMember[][]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\TeamMember[][]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\TeamMember[][]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1358,34 +1264,11 @@ public function getTeamsWithHttpInfo($ids, string $contentType = self::contentTy ); } - $returnType = '\Aternos\ModrinthApi\Model\TeamMember[][]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\TeamMember[][]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1395,8 +1278,10 @@ public function getTeamsWithHttpInfo($ids, string $contentType = self::contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1624,7 +1509,6 @@ public function joinTeamWithHttpInfo($id, string $contentType = self::contentTyp return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -1634,8 +1518,10 @@ public function joinTeamWithHttpInfo($id, string $contentType = self::contentTyp $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1858,7 +1744,6 @@ public function modifyTeamMemberWithHttpInfo($id, $id_username, $modify_team_mem return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -1868,8 +1753,10 @@ public function modifyTeamMemberWithHttpInfo($id, $id_username, $modify_team_mem $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2119,7 +2006,6 @@ public function transferTeamOwnershipWithHttpInfo($id, $user_identifier = null, return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -2129,8 +2015,10 @@ public function transferTeamOwnershipWithHttpInfo($id, $user_identifier = null, $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2319,6 +2207,57 @@ protected function createHttpClientOption() } } + if ($this->config->getCertFile()) { + $options[RequestOptions::CERT] = $this->config->getCertFile(); + } + + if ($this->config->getKeyFile()) { + $options[RequestOptions::SSL_KEY] = $this->config->getKeyFile(); + } + return $options; } + + private function handleResponseWithDataType( + string $dataType, + RequestInterface $request, + ResponseInterface $response + ): array { + if ($dataType === '\SplFileObject') { + $content = $response->getBody(); //stream goes to serializer + } else { + $content = (string) $response->getBody(); + if ($dataType !== 'string') { + try { + $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); + } catch (\JsonException $exception) { + throw new ApiException( + sprintf( + 'Error JSON decoding server response (%s)', + $request->getUri() + ), + $response->getStatusCode(), + $response->getHeaders(), + $content + ); + } + } + } + + return [ + ObjectSerializer::deserialize($content, $dataType, []), + $response->getStatusCode(), + $response->getHeaders() + ]; + } + + private function responseWithinRangeCode( + string $rangeCode, + int $statusCode + ): bool { + $left = (int) ($rangeCode[0].'00'); + $right = (int) ($rangeCode[0].'99'); + + return $statusCode >= $left && $statusCode <= $right; + } } diff --git a/lib/Api/ThreadsApi.php b/lib/Api/ThreadsApi.php index f6a8a7f..8a69978 100644 --- a/lib/Api/ThreadsApi.php +++ b/lib/Api/ThreadsApi.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -35,8 +35,11 @@ use GuzzleHttp\Psr7\MultipartStream; use GuzzleHttp\Psr7\Request; use GuzzleHttp\RequestOptions; +use Psr\Http\Message\RequestInterface; +use Psr\Http\Message\ResponseInterface; use Aternos\ModrinthApi\ApiException; use Aternos\ModrinthApi\Configuration; +use Aternos\ModrinthApi\FormDataProcessor; use Aternos\ModrinthApi\HeaderSelector; use Aternos\ModrinthApi\ObjectSerializer; @@ -204,7 +207,6 @@ public function deleteThreadMessageWithHttpInfo($id, string $contentType = self: return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -214,8 +216,10 @@ public function deleteThreadMessageWithHttpInfo($id, string $contentType = self: $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -436,61 +440,21 @@ public function getOpenReportsWithHttpInfo($count = null, string $contentType = switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Report[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Report[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Report[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Report[]', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -504,34 +468,11 @@ public function getOpenReportsWithHttpInfo($count = null, string $contentType = ); } - $returnType = '\Aternos\ModrinthApi\Model\Report[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Report[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -541,7 +482,7 @@ public function getOpenReportsWithHttpInfo($count = null, string $contentType = $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -549,8 +490,10 @@ public function getOpenReportsWithHttpInfo($count = null, string $contentType = $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -779,61 +722,21 @@ public function getReportWithHttpInfo($id, string $contentType = self::contentTy switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Report' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Report' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Report', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Report', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -847,34 +750,11 @@ public function getReportWithHttpInfo($id, string $contentType = self::contentTy ); } - $returnType = '\Aternos\ModrinthApi\Model\Report'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Report', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -884,7 +764,7 @@ public function getReportWithHttpInfo($id, string $contentType = self::contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -892,8 +772,10 @@ public function getReportWithHttpInfo($id, string $contentType = self::contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1127,61 +1009,21 @@ public function getReportsWithHttpInfo($ids, string $contentType = self::content switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Report[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Report[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Report[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Report[]', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1195,34 +1037,11 @@ public function getReportsWithHttpInfo($ids, string $contentType = self::content ); } - $returnType = '\Aternos\ModrinthApi\Model\Report[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Report[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1232,7 +1051,7 @@ public function getReportsWithHttpInfo($ids, string $contentType = self::content $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -1240,8 +1059,10 @@ public function getReportsWithHttpInfo($ids, string $contentType = self::content $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1476,34 +1297,15 @@ public function getThreadWithHttpInfo($id, string $contentType = self::contentTy switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Thread' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Thread' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Thread', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Thread', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1517,34 +1319,11 @@ public function getThreadWithHttpInfo($id, string $contentType = self::contentTy ); } - $returnType = '\Aternos\ModrinthApi\Model\Thread'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Thread', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1554,8 +1333,10 @@ public function getThreadWithHttpInfo($id, string $contentType = self::contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1789,34 +1570,15 @@ public function getThreadsWithHttpInfo($ids, string $contentType = self::content switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Thread[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Thread[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Thread[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Thread[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1830,34 +1592,11 @@ public function getThreadsWithHttpInfo($ids, string $contentType = self::content ); } - $returnType = '\Aternos\ModrinthApi\Model\Thread[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Thread[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1867,8 +1606,10 @@ public function getThreadsWithHttpInfo($ids, string $contentType = self::content $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2103,7 +1844,6 @@ public function modifyReportWithHttpInfo($id, $modify_report_request = null, str return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -2113,7 +1853,7 @@ public function modifyReportWithHttpInfo($id, $modify_report_request = null, str $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -2121,8 +1861,10 @@ public function modifyReportWithHttpInfo($id, $modify_report_request = null, str $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2356,61 +2098,21 @@ public function sendThreadMessageWithHttpInfo($id, $thread_message_body = null, switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Thread' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Thread' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Thread', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Thread', + $request, + $response, + ); case 400: - if ('\Aternos\ModrinthApi\Model\InvalidInputError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\InvalidInputError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\InvalidInputError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\InvalidInputError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -2424,34 +2126,11 @@ public function sendThreadMessageWithHttpInfo($id, $thread_message_body = null, ); } - $returnType = '\Aternos\ModrinthApi\Model\Thread'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Thread', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -2461,7 +2140,7 @@ public function sendThreadMessageWithHttpInfo($id, $thread_message_body = null, $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 400: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -2469,8 +2148,10 @@ public function sendThreadMessageWithHttpInfo($id, $thread_message_body = null, $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2715,88 +2396,27 @@ public function submitReportWithHttpInfo($creatable_report = null, string $conte switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Report' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Report' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Report', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Report', + $request, + $response, + ); case 400: - if ('\Aternos\ModrinthApi\Model\InvalidInputError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\InvalidInputError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\InvalidInputError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\InvalidInputError', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -2810,34 +2430,11 @@ public function submitReportWithHttpInfo($creatable_report = null, string $conte ); } - $returnType = '\Aternos\ModrinthApi\Model\Report'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Report', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -2847,7 +2444,7 @@ public function submitReportWithHttpInfo($creatable_report = null, string $conte $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 400: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -2855,7 +2452,7 @@ public function submitReportWithHttpInfo($creatable_report = null, string $conte $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -2863,8 +2460,10 @@ public function submitReportWithHttpInfo($creatable_report = null, string $conte $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -3048,6 +2647,57 @@ protected function createHttpClientOption() } } + if ($this->config->getCertFile()) { + $options[RequestOptions::CERT] = $this->config->getCertFile(); + } + + if ($this->config->getKeyFile()) { + $options[RequestOptions::SSL_KEY] = $this->config->getKeyFile(); + } + return $options; } + + private function handleResponseWithDataType( + string $dataType, + RequestInterface $request, + ResponseInterface $response + ): array { + if ($dataType === '\SplFileObject') { + $content = $response->getBody(); //stream goes to serializer + } else { + $content = (string) $response->getBody(); + if ($dataType !== 'string') { + try { + $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); + } catch (\JsonException $exception) { + throw new ApiException( + sprintf( + 'Error JSON decoding server response (%s)', + $request->getUri() + ), + $response->getStatusCode(), + $response->getHeaders(), + $content + ); + } + } + } + + return [ + ObjectSerializer::deserialize($content, $dataType, []), + $response->getStatusCode(), + $response->getHeaders() + ]; + } + + private function responseWithinRangeCode( + string $rangeCode, + int $statusCode + ): bool { + $left = (int) ($rangeCode[0].'00'); + $right = (int) ($rangeCode[0].'99'); + + return $statusCode >= $left && $statusCode <= $right; + } } diff --git a/lib/Api/UsersApi.php b/lib/Api/UsersApi.php index d824db4..de33c80 100644 --- a/lib/Api/UsersApi.php +++ b/lib/Api/UsersApi.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -35,8 +35,11 @@ use GuzzleHttp\Psr7\MultipartStream; use GuzzleHttp\Psr7\Request; use GuzzleHttp\RequestOptions; +use Psr\Http\Message\RequestInterface; +use Psr\Http\Message\ResponseInterface; use Aternos\ModrinthApi\ApiException; use Aternos\ModrinthApi\Configuration; +use Aternos\ModrinthApi\FormDataProcessor; use Aternos\ModrinthApi\HeaderSelector; use Aternos\ModrinthApi\ObjectSerializer; @@ -82,6 +85,9 @@ class UsersApi 'image/svgz', 'image/rgb', ], + 'deleteUserIcon' => [ + 'application/json', + ], 'getFollowedProjects' => [ 'application/json', ], @@ -213,7 +219,6 @@ public function changeUserIconWithHttpInfo($id_username, $body = null, string $c return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -223,8 +228,10 @@ public function changeUserIconWithHttpInfo($id_username, $body = null, string $c $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -397,6 +404,237 @@ public function changeUserIconRequest($id_username, $body = null, string $conten ); } + /** + * Operation deleteUserIcon + * + * Remove user's avatar + * + * @param string $id_username The ID or username of the user (required) + * @param string $contentType The value for the Content-Type header. Check self::contentTypes['deleteUserIcon'] to see the possible values for this operation + * + * @throws \Aternos\ModrinthApi\ApiException on non-2xx response or if the response body is not in the expected format + * @throws \InvalidArgumentException + * @return void + */ + public function deleteUserIcon($id_username, string $contentType = self::contentTypes['deleteUserIcon'][0]) + { + $this->deleteUserIconWithHttpInfo($id_username, $contentType); + } + + /** + * Operation deleteUserIconWithHttpInfo + * + * Remove user's avatar + * + * @param string $id_username The ID or username of the user (required) + * @param string $contentType The value for the Content-Type header. Check self::contentTypes['deleteUserIcon'] to see the possible values for this operation + * + * @throws \Aternos\ModrinthApi\ApiException on non-2xx response or if the response body is not in the expected format + * @throws \InvalidArgumentException + * @return array of null, HTTP status code, HTTP response headers (array of strings) + */ + public function deleteUserIconWithHttpInfo($id_username, string $contentType = self::contentTypes['deleteUserIcon'][0]) + { + $request = $this->deleteUserIconRequest($id_username, $contentType); + + try { + $options = $this->createHttpClientOption(); + try { + $response = $this->client->send($request, $options); + } catch (RequestException $e) { + throw new ApiException( + "[{$e->getCode()}] {$e->getMessage()}", + (int) $e->getCode(), + $e->getResponse() ? $e->getResponse()->getHeaders() : null, + $e->getResponse() ? (string) $e->getResponse()->getBody() : null + ); + } catch (ConnectException $e) { + throw new ApiException( + "[{$e->getCode()}] {$e->getMessage()}", + (int) $e->getCode(), + null, + null + ); + } + + $statusCode = $response->getStatusCode(); + + + return [null, $statusCode, $response->getHeaders()]; + } catch (ApiException $e) { + switch ($e->getCode()) { + case 400: + $data = ObjectSerializer::deserialize( + $e->getResponseBody(), + '\Aternos\ModrinthApi\Model\InvalidInputError', + $e->getResponseHeaders() + ); + $e->setResponseObject($data); + throw $e; + } + + + throw $e; + } + } + + /** + * Operation deleteUserIconAsync + * + * Remove user's avatar + * + * @param string $id_username The ID or username of the user (required) + * @param string $contentType The value for the Content-Type header. Check self::contentTypes['deleteUserIcon'] to see the possible values for this operation + * + * @throws \InvalidArgumentException + * @return \GuzzleHttp\Promise\PromiseInterface + */ + public function deleteUserIconAsync($id_username, string $contentType = self::contentTypes['deleteUserIcon'][0]) + { + return $this->deleteUserIconAsyncWithHttpInfo($id_username, $contentType) + ->then( + function ($response) { + return $response[0]; + } + ); + } + + /** + * Operation deleteUserIconAsyncWithHttpInfo + * + * Remove user's avatar + * + * @param string $id_username The ID or username of the user (required) + * @param string $contentType The value for the Content-Type header. Check self::contentTypes['deleteUserIcon'] to see the possible values for this operation + * + * @throws \InvalidArgumentException + * @return \GuzzleHttp\Promise\PromiseInterface + */ + public function deleteUserIconAsyncWithHttpInfo($id_username, string $contentType = self::contentTypes['deleteUserIcon'][0]) + { + $returnType = ''; + $request = $this->deleteUserIconRequest($id_username, $contentType); + + return $this->client + ->sendAsync($request, $this->createHttpClientOption()) + ->then( + function ($response) use ($returnType) { + return [null, $response->getStatusCode(), $response->getHeaders()]; + }, + function ($exception) { + $response = $exception->getResponse(); + $statusCode = $response->getStatusCode(); + throw new ApiException( + sprintf( + '[%d] Error connecting to the API (%s)', + $statusCode, + $exception->getRequest()->getUri() + ), + $statusCode, + $response->getHeaders(), + (string) $response->getBody() + ); + } + ); + } + + /** + * Create request for operation 'deleteUserIcon' + * + * @param string $id_username The ID or username of the user (required) + * @param string $contentType The value for the Content-Type header. Check self::contentTypes['deleteUserIcon'] to see the possible values for this operation + * + * @throws \InvalidArgumentException + * @return \GuzzleHttp\Psr7\Request + */ + public function deleteUserIconRequest($id_username, string $contentType = self::contentTypes['deleteUserIcon'][0]) + { + + // verify the required parameter 'id_username' is set + if ($id_username === null || (is_array($id_username) && count($id_username) === 0)) { + throw new \InvalidArgumentException( + 'Missing the required parameter $id_username when calling deleteUserIcon' + ); + } + + + $resourcePath = '/user/{id|username}/icon'; + $formParams = []; + $queryParams = []; + $headerParams = []; + $httpBody = ''; + $multipart = false; + + + + // path params + if ($id_username !== null) { + $resourcePath = str_replace( + '{' . 'id|username' . '}', + ObjectSerializer::toPathValue($id_username), + $resourcePath + ); + } + + + $headers = $this->headerSelector->selectHeaders( + ['application/json', ], + $contentType, + $multipart + ); + + // for model (json/xml) + if (count($formParams) > 0) { + if ($multipart) { + $multipartContents = []; + foreach ($formParams as $formParamName => $formParamValue) { + $formParamValueItems = is_array($formParamValue) ? $formParamValue : [$formParamValue]; + foreach ($formParamValueItems as $formParamValueItem) { + $multipartContents[] = [ + 'name' => $formParamName, + 'contents' => $formParamValueItem + ]; + } + } + // for HTTP post (form) + $httpBody = new MultipartStream($multipartContents); + + } elseif (stripos($headers['Content-Type'], 'application/json') !== false) { + # if Content-Type contains "application/json", json_encode the form parameters + $httpBody = \GuzzleHttp\Utils::jsonEncode($formParams); + } else { + // for HTTP post (form) + $httpBody = ObjectSerializer::buildQuery($formParams); + } + } + + // this endpoint requires API key authentication + $apiKey = $this->config->getApiKeyWithPrefix('Authorization'); + if ($apiKey !== null) { + $headers['Authorization'] = $apiKey; + } + + $defaultHeaders = []; + if ($this->config->getUserAgent()) { + $defaultHeaders['User-Agent'] = $this->config->getUserAgent(); + } + + $headers = array_merge( + $defaultHeaders, + $headerParams, + $headers + ); + + $operationHost = $this->config->getHost(); + $query = ObjectSerializer::buildQuery($queryParams); + return new Request( + 'DELETE', + $operationHost . $resourcePath . ($query ? "?{$query}" : ''), + $headers, + $httpBody + ); + } + /** * Operation getFollowedProjects * @@ -456,61 +694,21 @@ public function getFollowedProjectsWithHttpInfo($id_username, string $contentTyp switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Project[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Project[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Project[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project[]', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -524,34 +722,11 @@ public function getFollowedProjectsWithHttpInfo($id_username, string $contentTyp ); } - $returnType = '\Aternos\ModrinthApi\Model\Project[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -561,7 +736,7 @@ public function getFollowedProjectsWithHttpInfo($id_username, string $contentTyp $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -569,8 +744,10 @@ public function getFollowedProjectsWithHttpInfo($id_username, string $contentTyp $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -804,61 +981,21 @@ public function getPayoutHistoryWithHttpInfo($id_username, string $contentType = switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\UserPayoutHistory' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\UserPayoutHistory' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\UserPayoutHistory', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\UserPayoutHistory', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -872,34 +1009,11 @@ public function getPayoutHistoryWithHttpInfo($id_username, string $contentType = ); } - $returnType = '\Aternos\ModrinthApi\Model\UserPayoutHistory'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\UserPayoutHistory', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -909,7 +1023,7 @@ public function getPayoutHistoryWithHttpInfo($id_username, string $contentType = $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -917,8 +1031,10 @@ public function getPayoutHistoryWithHttpInfo($id_username, string $contentType = $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1152,34 +1268,15 @@ public function getUserWithHttpInfo($id_username, string $contentType = self::co switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\User' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\User' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\User', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\User', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1193,34 +1290,11 @@ public function getUserWithHttpInfo($id_username, string $contentType = self::co ); } - $returnType = '\Aternos\ModrinthApi\Model\User'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\User', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1230,8 +1304,10 @@ public function getUserWithHttpInfo($id_username, string $contentType = self::co $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1458,61 +1534,21 @@ public function getUserFromAuthWithHttpInfo(string $contentType = self::contentT switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\User' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\User' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\User', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\User', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1526,34 +1562,11 @@ public function getUserFromAuthWithHttpInfo(string $contentType = self::contentT ); } - $returnType = '\Aternos\ModrinthApi\Model\User'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\User', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1563,7 +1576,7 @@ public function getUserFromAuthWithHttpInfo(string $contentType = self::contentT $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -1571,8 +1584,10 @@ public function getUserFromAuthWithHttpInfo(string $contentType = self::contentT $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1788,34 +1803,15 @@ public function getUserProjectsWithHttpInfo($id_username, string $contentType = switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Project[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Project[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Project[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1829,34 +1825,11 @@ public function getUserProjectsWithHttpInfo($id_username, string $contentType = ); } - $returnType = '\Aternos\ModrinthApi\Model\Project[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Project[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1866,8 +1839,10 @@ public function getUserProjectsWithHttpInfo($id_username, string $contentType = $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2096,34 +2071,15 @@ public function getUsersWithHttpInfo($ids, string $contentType = self::contentTy switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\User[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\User[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\User[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\User[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -2137,34 +2093,11 @@ public function getUsersWithHttpInfo($ids, string $contentType = self::contentTy ); } - $returnType = '\Aternos\ModrinthApi\Model\User[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\User[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -2174,8 +2107,10 @@ public function getUsersWithHttpInfo($ids, string $contentType = self::contentTy $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2405,7 +2340,6 @@ public function modifyUserWithHttpInfo($id_username, $editable_user = null, stri return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -2415,8 +2349,10 @@ public function modifyUserWithHttpInfo($id_username, $editable_user = null, stri $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2648,7 +2584,6 @@ public function withdrawPayoutWithHttpInfo($id_username, $amount, string $conten return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -2658,8 +2593,10 @@ public function withdrawPayoutWithHttpInfo($id_username, $amount, string $conten $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2856,6 +2793,57 @@ protected function createHttpClientOption() } } + if ($this->config->getCertFile()) { + $options[RequestOptions::CERT] = $this->config->getCertFile(); + } + + if ($this->config->getKeyFile()) { + $options[RequestOptions::SSL_KEY] = $this->config->getKeyFile(); + } + return $options; } + + private function handleResponseWithDataType( + string $dataType, + RequestInterface $request, + ResponseInterface $response + ): array { + if ($dataType === '\SplFileObject') { + $content = $response->getBody(); //stream goes to serializer + } else { + $content = (string) $response->getBody(); + if ($dataType !== 'string') { + try { + $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); + } catch (\JsonException $exception) { + throw new ApiException( + sprintf( + 'Error JSON decoding server response (%s)', + $request->getUri() + ), + $response->getStatusCode(), + $response->getHeaders(), + $content + ); + } + } + } + + return [ + ObjectSerializer::deserialize($content, $dataType, []), + $response->getStatusCode(), + $response->getHeaders() + ]; + } + + private function responseWithinRangeCode( + string $rangeCode, + int $statusCode + ): bool { + $left = (int) ($rangeCode[0].'00'); + $right = (int) ($rangeCode[0].'99'); + + return $statusCode >= $left && $statusCode <= $right; + } } diff --git a/lib/Api/VersionFilesApi.php b/lib/Api/VersionFilesApi.php index 8d50755..6a26202 100644 --- a/lib/Api/VersionFilesApi.php +++ b/lib/Api/VersionFilesApi.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -35,8 +35,11 @@ use GuzzleHttp\Psr7\MultipartStream; use GuzzleHttp\Psr7\Request; use GuzzleHttp\RequestOptions; +use Psr\Http\Message\RequestInterface; +use Psr\Http\Message\ResponseInterface; use Aternos\ModrinthApi\ApiException; use Aternos\ModrinthApi\Configuration; +use Aternos\ModrinthApi\FormDataProcessor; use Aternos\ModrinthApi\HeaderSelector; use Aternos\ModrinthApi\ObjectSerializer; @@ -196,7 +199,6 @@ public function deleteFileFromHashWithHttpInfo($hash, $algorithm, $version_id = return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -206,8 +208,10 @@ public function deleteFileFromHashWithHttpInfo($hash, $algorithm, $version_id = $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -464,34 +468,15 @@ public function getLatestVersionFromHashWithHttpInfo($hash, $algorithm, $get_lat switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Version' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Version' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Version', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -505,34 +490,11 @@ public function getLatestVersionFromHashWithHttpInfo($hash, $algorithm, $get_lat ); } - $returnType = '\Aternos\ModrinthApi\Model\Version'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -542,8 +504,10 @@ public function getLatestVersionFromHashWithHttpInfo($hash, $algorithm, $get_lat $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -802,34 +766,15 @@ public function getLatestVersionsFromHashesWithHttpInfo($get_latest_versions_fro switch($statusCode) { case 200: - if ('array' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('array' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, 'array', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + 'array', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -843,34 +788,11 @@ public function getLatestVersionsFromHashesWithHttpInfo($get_latest_versions_fro ); } - $returnType = 'array'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + 'array', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -880,8 +802,10 @@ public function getLatestVersionsFromHashesWithHttpInfo($get_latest_versions_fro $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1107,34 +1031,15 @@ public function versionFromHashWithHttpInfo($hash, $algorithm, $multiple = false switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Version' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Version' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Version', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1148,34 +1053,11 @@ public function versionFromHashWithHttpInfo($hash, $algorithm, $multiple = false ); } - $returnType = '\Aternos\ModrinthApi\Model\Version'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1185,8 +1067,10 @@ public function versionFromHashWithHttpInfo($hash, $algorithm, $multiple = false $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1447,34 +1331,15 @@ public function versionsFromHashesWithHttpInfo($hash_list = null, string $conten switch($statusCode) { case 200: - if ('array' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('array' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, 'array', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + 'array', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1488,34 +1353,11 @@ public function versionsFromHashesWithHttpInfo($hash_list = null, string $conten ); } - $returnType = 'array'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + 'array', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1525,8 +1367,10 @@ public function versionsFromHashesWithHttpInfo($hash_list = null, string $conten $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1705,6 +1549,57 @@ protected function createHttpClientOption() } } + if ($this->config->getCertFile()) { + $options[RequestOptions::CERT] = $this->config->getCertFile(); + } + + if ($this->config->getKeyFile()) { + $options[RequestOptions::SSL_KEY] = $this->config->getKeyFile(); + } + return $options; } + + private function handleResponseWithDataType( + string $dataType, + RequestInterface $request, + ResponseInterface $response + ): array { + if ($dataType === '\SplFileObject') { + $content = $response->getBody(); //stream goes to serializer + } else { + $content = (string) $response->getBody(); + if ($dataType !== 'string') { + try { + $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); + } catch (\JsonException $exception) { + throw new ApiException( + sprintf( + 'Error JSON decoding server response (%s)', + $request->getUri() + ), + $response->getStatusCode(), + $response->getHeaders(), + $content + ); + } + } + } + + return [ + ObjectSerializer::deserialize($content, $dataType, []), + $response->getStatusCode(), + $response->getHeaders() + ]; + } + + private function responseWithinRangeCode( + string $rangeCode, + int $statusCode + ): bool { + $left = (int) ($rangeCode[0].'00'); + $right = (int) ($rangeCode[0].'99'); + + return $statusCode >= $left && $statusCode <= $right; + } } diff --git a/lib/Api/VersionsApi.php b/lib/Api/VersionsApi.php index 930b506..ed827e9 100644 --- a/lib/Api/VersionsApi.php +++ b/lib/Api/VersionsApi.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -35,8 +35,11 @@ use GuzzleHttp\Psr7\MultipartStream; use GuzzleHttp\Psr7\Request; use GuzzleHttp\RequestOptions; +use Psr\Http\Message\RequestInterface; +use Psr\Http\Message\ResponseInterface; use Aternos\ModrinthApi\ApiException; use Aternos\ModrinthApi\Configuration; +use Aternos\ModrinthApi\FormDataProcessor; use Aternos\ModrinthApi\HeaderSelector; use Aternos\ModrinthApi\ObjectSerializer; @@ -206,7 +209,6 @@ public function addFilesToVersionWithHttpInfo($id, $data = null, string $content return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -216,8 +218,10 @@ public function addFilesToVersionWithHttpInfo($id, $data = null, string $content $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -325,9 +329,14 @@ public function addFilesToVersionRequest($id, $data = null, string $contentType } // form params - if ($data !== null) { - $formParams['data'] = ObjectSerializer::toFormValue($data); - } + $formDataProcessor = new FormDataProcessor(); + + $formData = $formDataProcessor->prepare([ + 'data' => $data, + ]); + + $formParams = $formDataProcessor->flatten($formData); + $multipart = $formDataProcessor->has_file; $multipart = true; $headers = $this->headerSelector->selectHeaders( @@ -447,88 +456,27 @@ public function createVersionWithHttpInfo($data, string $contentType = self::con switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Version' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Version' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Version', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version', + $request, + $response, + ); case 400: - if ('\Aternos\ModrinthApi\Model\InvalidInputError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\InvalidInputError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\InvalidInputError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\InvalidInputError', + $request, + $response, + ); case 401: - if ('\Aternos\ModrinthApi\Model\AuthError' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\AuthError' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\AuthError', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\AuthError', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -542,34 +490,11 @@ public function createVersionWithHttpInfo($data, string $contentType = self::con ); } - $returnType = '\Aternos\ModrinthApi\Model\Version'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -579,7 +504,7 @@ public function createVersionWithHttpInfo($data, string $contentType = self::con $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 400: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -587,7 +512,7 @@ public function createVersionWithHttpInfo($data, string $contentType = self::con $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -595,8 +520,10 @@ public function createVersionWithHttpInfo($data, string $contentType = self::con $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -705,9 +632,14 @@ public function createVersionRequest($data, string $contentType = self::contentT // form params - if ($data !== null) { - $formParams['data'] = ObjectSerializer::toFormValue($data); - } + $formDataProcessor = new FormDataProcessor(); + + $formData = $formDataProcessor->prepare([ + 'data' => $data, + ]); + + $formParams = $formDataProcessor->flatten($formData); + $multipart = $formDataProcessor->has_file; $multipart = true; $headers = $this->headerSelector->selectHeaders( @@ -825,7 +757,6 @@ public function deleteVersionWithHttpInfo($id, string $contentType = self::conte return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -835,8 +766,10 @@ public function deleteVersionWithHttpInfo($id, string $contentType = self::conte $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1063,34 +996,15 @@ public function getProjectVersionsWithHttpInfo($id_slug, $loaders = null, $game_ switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Version[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Version[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Version[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1104,34 +1018,11 @@ public function getProjectVersionsWithHttpInfo($id_slug, $loaders = null, $game_ ); } - $returnType = '\Aternos\ModrinthApi\Model\Version[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1141,8 +1032,10 @@ public function getProjectVersionsWithHttpInfo($id_slug, $loaders = null, $game_ $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1410,34 +1303,15 @@ public function getVersionWithHttpInfo($id, string $contentType = self::contentT switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Version' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Version' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Version', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1451,34 +1325,11 @@ public function getVersionWithHttpInfo($id, string $contentType = self::contentT ); } - $returnType = '\Aternos\ModrinthApi\Model\Version'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1488,8 +1339,10 @@ public function getVersionWithHttpInfo($id, string $contentType = self::contentT $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -1720,34 +1573,15 @@ public function getVersionFromIdOrNumberWithHttpInfo($id_slug, $id_number, strin switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Version' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Version' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Version', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -1761,34 +1595,11 @@ public function getVersionFromIdOrNumberWithHttpInfo($id_slug, $id_number, strin ); } - $returnType = '\Aternos\ModrinthApi\Model\Version'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -1798,8 +1609,10 @@ public function getVersionFromIdOrNumberWithHttpInfo($id_slug, $id_number, strin $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2046,34 +1859,15 @@ public function getVersionsWithHttpInfo($ids, string $contentType = self::conten switch($statusCode) { case 200: - if ('\Aternos\ModrinthApi\Model\Version[]' === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ('\Aternos\ModrinthApi\Model\Version[]' !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, '\Aternos\ModrinthApi\Model\Version[]', []), - $response->getStatusCode(), - $response->getHeaders() - ]; + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version[]', + $request, + $response, + ); } + + if ($statusCode < 200 || $statusCode > 299) { throw new ApiException( sprintf( @@ -2087,34 +1881,11 @@ public function getVersionsWithHttpInfo($ids, string $contentType = self::conten ); } - $returnType = '\Aternos\ModrinthApi\Model\Version[]'; - if ($returnType === '\SplFileObject') { - $content = $response->getBody(); //stream goes to serializer - } else { - $content = (string) $response->getBody(); - if ($returnType !== 'string') { - try { - $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); - } catch (\JsonException $exception) { - throw new ApiException( - sprintf( - 'Error JSON decoding server response (%s)', - $request->getUri() - ), - $statusCode, - $response->getHeaders(), - $content - ); - } - } - } - - return [ - ObjectSerializer::deserialize($content, $returnType, []), - $response->getStatusCode(), - $response->getHeaders() - ]; - + return $this->handleResponseWithDataType( + '\Aternos\ModrinthApi\Model\Version[]', + $request, + $response, + ); } catch (ApiException $e) { switch ($e->getCode()) { case 200: @@ -2124,8 +1895,10 @@ public function getVersionsWithHttpInfo($ids, string $contentType = self::conten $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2355,7 +2128,6 @@ public function modifyVersionWithHttpInfo($id, $editable_version = null, string return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 401: @@ -2365,8 +2137,10 @@ public function modifyVersionWithHttpInfo($id, $editable_version = null, string $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2598,7 +2372,6 @@ public function scheduleVersionWithHttpInfo($id, $schedule = null, string $conte return [null, $statusCode, $response->getHeaders()]; - } catch (ApiException $e) { switch ($e->getCode()) { case 400: @@ -2608,7 +2381,7 @@ public function scheduleVersionWithHttpInfo($id, $schedule = null, string $conte $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; case 401: $data = ObjectSerializer::deserialize( $e->getResponseBody(), @@ -2616,8 +2389,10 @@ public function scheduleVersionWithHttpInfo($id, $schedule = null, string $conte $e->getResponseHeaders() ); $e->setResponseObject($data); - break; + throw $e; } + + throw $e; } } @@ -2806,6 +2581,57 @@ protected function createHttpClientOption() } } + if ($this->config->getCertFile()) { + $options[RequestOptions::CERT] = $this->config->getCertFile(); + } + + if ($this->config->getKeyFile()) { + $options[RequestOptions::SSL_KEY] = $this->config->getKeyFile(); + } + return $options; } + + private function handleResponseWithDataType( + string $dataType, + RequestInterface $request, + ResponseInterface $response + ): array { + if ($dataType === '\SplFileObject') { + $content = $response->getBody(); //stream goes to serializer + } else { + $content = (string) $response->getBody(); + if ($dataType !== 'string') { + try { + $content = json_decode($content, false, 512, JSON_THROW_ON_ERROR); + } catch (\JsonException $exception) { + throw new ApiException( + sprintf( + 'Error JSON decoding server response (%s)', + $request->getUri() + ), + $response->getStatusCode(), + $response->getHeaders(), + $content + ); + } + } + } + + return [ + ObjectSerializer::deserialize($content, $dataType, []), + $response->getStatusCode(), + $response->getHeaders() + ]; + } + + private function responseWithinRangeCode( + string $rangeCode, + int $statusCode + ): bool { + $left = (int) ($rangeCode[0].'00'); + $right = (int) ($rangeCode[0].'99'); + + return $statusCode >= $left && $statusCode <= $right; + } } diff --git a/lib/ApiException.php b/lib/ApiException.php index f2e5762..78de20b 100644 --- a/lib/ApiException.php +++ b/lib/ApiException.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** diff --git a/lib/Configuration.php b/lib/Configuration.php index 1dc7f37..9349ec3 100644 --- a/lib/Configuration.php +++ b/lib/Configuration.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -30,7 +30,7 @@ /** * Configuration Class Doc Comment - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -124,6 +124,20 @@ class Configuration */ protected $tempFolderPath; + /** + * Path to a certificate file, for mTLS + * + * @var string + */ + protected $certFile; + + /** + * Path to a key file, for mTLS + * + * @var string + */ + protected $keyFile; + /** * Constructor */ @@ -397,6 +411,49 @@ public function getTempFolderPath() return $this->tempFolderPath; } + /** + * Sets the certificate file path, for mTLS + * + * @return $this + */ + public function setCertFile($certFile) + { + $this->certFile = $certFile; + return $this; + } + + /** + * Gets the certificate file path, for mTLS + * + * @return string Certificate file path + */ + public function getCertFile() + { + return $this->certFile; + } + + /** + * Sets the certificate key path, for mTLS + * + * @return $this + */ + public function setKeyFile($keyFile) + { + $this->keyFile = $keyFile; + return $this; + } + + /** + * Gets the certificate key path, for mTLS + * + * @return string Certificate key path + */ + public function getKeyFile() + { + return $this->keyFile; + } + + /** * Gets the default configuration instance * @@ -433,7 +490,7 @@ public static function toDebugReport() $report = 'PHP SDK (Aternos\ModrinthApi) Debug Report:' . PHP_EOL; $report .= ' OS: ' . php_uname() . PHP_EOL; $report .= ' PHP Version: ' . PHP_VERSION . PHP_EOL; - $report .= ' The version of the OpenAPI document: v2.7.0/15cf3fc' . PHP_EOL; + $report .= ' The version of the OpenAPI document: v2.7.0/366f528' . PHP_EOL; $report .= ' SDK Package Version: 2.1.4' . PHP_EOL; $report .= ' Temp Folder Path: ' . self::getDefaultConfiguration()->getTempFolderPath() . PHP_EOL; diff --git a/lib/HeaderSelector.php b/lib/HeaderSelector.php index be47f4c..955d0a4 100644 --- a/lib/HeaderSelector.php +++ b/lib/HeaderSelector.php @@ -1,7 +1,7 @@ &redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** diff --git a/lib/Model/AuthError.php b/lib/Model/AuthError.php index 2844378..1ac9511 100644 --- a/lib/Model/AuthError.php +++ b/lib/Model/AuthError.php @@ -2,7 +2,7 @@ /** * AuthError * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -359,11 +359,11 @@ public function setDescription($description) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -371,12 +371,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -401,11 +401,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/BaseProject.php b/lib/Model/BaseProject.php index 2a7d922..2c9e84e 100644 --- a/lib/Model/BaseProject.php +++ b/lib/Model/BaseProject.php @@ -2,7 +2,7 @@ /** * BaseProject * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -565,11 +565,11 @@ public function setServerSide($server_side) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -577,12 +577,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -607,11 +607,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/BaseVersion.php b/lib/Model/BaseVersion.php index 678a9f5..447baaf 100644 --- a/lib/Model/BaseVersion.php +++ b/lib/Model/BaseVersion.php @@ -2,7 +2,7 @@ /** * BaseVersion * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -755,11 +755,11 @@ public function setRequestedStatus($requested_status) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -767,12 +767,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -797,11 +797,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/CategoryTag.php b/lib/Model/CategoryTag.php index 00e43f3..3178fac 100644 --- a/lib/Model/CategoryTag.php +++ b/lib/Model/CategoryTag.php @@ -2,7 +2,7 @@ /** * CategoryTag * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -433,11 +433,11 @@ public function setHeader($header) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -445,12 +445,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -475,11 +475,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/CreatableProject.php b/lib/Model/CreatableProject.php index ce7d224..830ac6e 100644 --- a/lib/Model/CreatableProject.php +++ b/lib/Model/CreatableProject.php @@ -2,7 +2,7 @@ /** * CreatableProject * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -1274,11 +1274,11 @@ public function setGalleryItems($gallery_items) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -1286,12 +1286,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -1316,11 +1316,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/CreatableProjectGalleryItem.php b/lib/Model/CreatableProjectGalleryItem.php index ead8caf..cea1d14 100644 --- a/lib/Model/CreatableProjectGalleryItem.php +++ b/lib/Model/CreatableProjectGalleryItem.php @@ -2,7 +2,7 @@ /** * CreatableProjectGalleryItem * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -469,11 +469,11 @@ public function setOrdering($ordering) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -481,12 +481,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -511,11 +511,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/CreatableReport.php b/lib/Model/CreatableReport.php index 6f80363..a19369c 100644 --- a/lib/Model/CreatableReport.php +++ b/lib/Model/CreatableReport.php @@ -2,7 +2,7 @@ /** * CreatableReport * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -469,11 +469,11 @@ public function setBody($body) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -481,12 +481,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -511,11 +511,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/CreatableVersion.php b/lib/Model/CreatableVersion.php index 1d867ee..2aa3c49 100644 --- a/lib/Model/CreatableVersion.php +++ b/lib/Model/CreatableVersion.php @@ -2,7 +2,7 @@ /** * CreatableVersion * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -884,11 +884,11 @@ public function setPrimaryFile($primary_file) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -896,12 +896,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -926,11 +926,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/DonationPlatformTag.php b/lib/Model/DonationPlatformTag.php index 7a9c9f6..3b786e1 100644 --- a/lib/Model/DonationPlatformTag.php +++ b/lib/Model/DonationPlatformTag.php @@ -2,7 +2,7 @@ /** * DonationPlatformTag * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -359,11 +359,11 @@ public function setName($name) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -371,12 +371,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -401,11 +401,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/EditableFileType.php b/lib/Model/EditableFileType.php index b5d577b..9b5d0b2 100644 --- a/lib/Model/EditableFileType.php +++ b/lib/Model/EditableFileType.php @@ -2,7 +2,7 @@ /** * EditableFileType * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -437,11 +437,11 @@ public function setFileType($file_type) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -449,12 +449,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -479,11 +479,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/EditableProject.php b/lib/Model/EditableProject.php index a721068..0ff704e 100644 --- a/lib/Model/EditableProject.php +++ b/lib/Model/EditableProject.php @@ -2,7 +2,7 @@ /** * EditableProject * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -1153,11 +1153,11 @@ public function setModerationMessageBody($moderation_message_body) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -1165,12 +1165,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -1195,11 +1195,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/EditableUser.php b/lib/Model/EditableUser.php index de4857c..1a8589d 100644 --- a/lib/Model/EditableUser.php +++ b/lib/Model/EditableUser.php @@ -2,7 +2,7 @@ /** * EditableUser * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -479,11 +479,11 @@ public function setPayoutData($payout_data) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -491,12 +491,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -521,11 +521,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/EditableVersion.php b/lib/Model/EditableVersion.php index 3d9e01b..a67f956 100644 --- a/lib/Model/EditableVersion.php +++ b/lib/Model/EditableVersion.php @@ -2,7 +2,7 @@ /** * EditableVersion * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -823,11 +823,11 @@ public function setFileTypes($file_types) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -835,12 +835,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -865,11 +865,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ForgeUpdateCheckerPromos.php b/lib/Model/ForgeUpdateCheckerPromos.php index 780cfe4..4dcdf49 100644 --- a/lib/Model/ForgeUpdateCheckerPromos.php +++ b/lib/Model/ForgeUpdateCheckerPromos.php @@ -2,7 +2,7 @@ /** * ForgeUpdateCheckerPromos * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -354,11 +354,11 @@ public function setVersionLatest($version_latest) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -366,12 +366,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -396,11 +396,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ForgeUpdates.php b/lib/Model/ForgeUpdates.php index 26131b3..0991b6f 100644 --- a/lib/Model/ForgeUpdates.php +++ b/lib/Model/ForgeUpdates.php @@ -2,7 +2,7 @@ /** * ForgeUpdates * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -354,11 +354,11 @@ public function setPromos($promos) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -366,12 +366,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -396,11 +396,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/GalleryImage.php b/lib/Model/GalleryImage.php index dd5238e..92d3954 100644 --- a/lib/Model/GalleryImage.php +++ b/lib/Model/GalleryImage.php @@ -2,7 +2,7 @@ /** * GalleryImage * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -512,11 +512,11 @@ public function setOrdering($ordering) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -524,12 +524,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -554,11 +554,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/GameVersionTag.php b/lib/Model/GameVersionTag.php index 3d4948f..f1fd233 100644 --- a/lib/Model/GameVersionTag.php +++ b/lib/Model/GameVersionTag.php @@ -2,7 +2,7 @@ /** * GameVersionTag * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -471,11 +471,11 @@ public function setMajor($major) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -483,12 +483,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -513,11 +513,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/GetLatestVersionFromHashBody.php b/lib/Model/GetLatestVersionFromHashBody.php index 2e93706..23ed5bd 100644 --- a/lib/Model/GetLatestVersionFromHashBody.php +++ b/lib/Model/GetLatestVersionFromHashBody.php @@ -2,7 +2,7 @@ /** * GetLatestVersionFromHashBody * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -359,11 +359,11 @@ public function setGameVersions($game_versions) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -371,12 +371,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -401,11 +401,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/GetLatestVersionsFromHashesBody.php b/lib/Model/GetLatestVersionsFromHashesBody.php index 0a63782..588171f 100644 --- a/lib/Model/GetLatestVersionsFromHashesBody.php +++ b/lib/Model/GetLatestVersionsFromHashesBody.php @@ -2,7 +2,7 @@ /** * GetLatestVersionsFromHashesBody * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -467,11 +467,11 @@ public function setGameVersions($game_versions) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -479,12 +479,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -509,11 +509,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/HashList.php b/lib/Model/HashList.php index 282a78d..3f72f57 100644 --- a/lib/Model/HashList.php +++ b/lib/Model/HashList.php @@ -2,7 +2,7 @@ /** * HashList * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -394,11 +394,11 @@ public function setAlgorithm($algorithm) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -406,12 +406,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -436,11 +436,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/InvalidInputError.php b/lib/Model/InvalidInputError.php index 871de19..92eb88c 100644 --- a/lib/Model/InvalidInputError.php +++ b/lib/Model/InvalidInputError.php @@ -2,7 +2,7 @@ /** * InvalidInputError * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -359,11 +359,11 @@ public function setDescription($description) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -371,12 +371,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -401,11 +401,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/License.php b/lib/Model/License.php index 0216b16..624e5de 100644 --- a/lib/Model/License.php +++ b/lib/Model/License.php @@ -2,7 +2,7 @@ /** * License * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -354,11 +354,11 @@ public function setBody($body) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -366,12 +366,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -396,11 +396,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/LicenseTag.php b/lib/Model/LicenseTag.php index 3de21e2..1052028 100644 --- a/lib/Model/LicenseTag.php +++ b/lib/Model/LicenseTag.php @@ -2,7 +2,7 @@ /** * LicenseTag * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -360,11 +360,11 @@ public function setName($name) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -372,12 +372,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -402,11 +402,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/LoaderTag.php b/lib/Model/LoaderTag.php index de1e177..f67b58e 100644 --- a/lib/Model/LoaderTag.php +++ b/lib/Model/LoaderTag.php @@ -2,7 +2,7 @@ /** * LoaderTag * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -396,11 +396,11 @@ public function setSupportedProjectTypes($supported_project_types) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -408,12 +408,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -438,11 +438,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ModelInterface.php b/lib/Model/ModelInterface.php index 02110d5..5699c04 100644 --- a/lib/Model/ModelInterface.php +++ b/lib/Model/ModelInterface.php @@ -2,7 +2,7 @@ /** * ModelInterface * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi\Model @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** diff --git a/lib/Model/ModeratorMessage.php b/lib/Model/ModeratorMessage.php index d751d36..a58b689 100644 --- a/lib/Model/ModeratorMessage.php +++ b/lib/Model/ModeratorMessage.php @@ -2,7 +2,7 @@ /** * ModeratorMessage * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -361,11 +361,11 @@ public function setBody($body) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -373,12 +373,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -403,11 +403,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ModifiableProject.php b/lib/Model/ModifiableProject.php index 526508b..450ea32 100644 --- a/lib/Model/ModifiableProject.php +++ b/lib/Model/ModifiableProject.php @@ -2,7 +2,7 @@ /** * ModifiableProject * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -1071,11 +1071,11 @@ public function setLicenseUrl($license_url) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -1083,12 +1083,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -1113,11 +1113,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ModifyReportRequest.php b/lib/Model/ModifyReportRequest.php index b168141..4683ca5 100644 --- a/lib/Model/ModifyReportRequest.php +++ b/lib/Model/ModifyReportRequest.php @@ -2,7 +2,7 @@ /** * ModifyReportRequest * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -353,11 +353,11 @@ public function setClosed($closed) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -365,12 +365,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -395,11 +395,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ModifyTeamMemberBody.php b/lib/Model/ModifyTeamMemberBody.php index b1ac5a5..350c852 100644 --- a/lib/Model/ModifyTeamMemberBody.php +++ b/lib/Model/ModifyTeamMemberBody.php @@ -2,7 +2,7 @@ /** * ModifyTeamMemberBody * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -421,11 +421,11 @@ public function setOrdering($ordering) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -433,12 +433,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -463,11 +463,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/NonSearchProject.php b/lib/Model/NonSearchProject.php index a98a757..ff3d034 100644 --- a/lib/Model/NonSearchProject.php +++ b/lib/Model/NonSearchProject.php @@ -2,7 +2,7 @@ /** * NonSearchProject * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -996,11 +996,11 @@ public function setDonationUrls($donation_urls) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -1008,12 +1008,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -1038,11 +1038,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/Notification.php b/lib/Model/Notification.php index b5fd529..75e116a 100644 --- a/lib/Model/Notification.php +++ b/lib/Model/Notification.php @@ -2,7 +2,7 @@ /** * Notification * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -660,11 +660,11 @@ public function setActions($actions) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -672,12 +672,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -702,11 +702,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/NotificationAction.php b/lib/Model/NotificationAction.php index fc2055b..20c811d 100644 --- a/lib/Model/NotificationAction.php +++ b/lib/Model/NotificationAction.php @@ -2,7 +2,7 @@ /** * NotificationAction * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -354,11 +354,11 @@ public function setActionRoute($action_route) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -366,12 +366,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -396,11 +396,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/PatchProjectsBody.php b/lib/Model/PatchProjectsBody.php index f3b4d86..f240843 100644 --- a/lib/Model/PatchProjectsBody.php +++ b/lib/Model/PatchProjectsBody.php @@ -2,7 +2,7 @@ /** * PatchProjectsBody * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -755,11 +755,11 @@ public function setDiscordUrl($discord_url) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -767,12 +767,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -797,11 +797,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/Project.php b/lib/Model/Project.php index b54fd0b..f1c08cb 100644 --- a/lib/Model/Project.php +++ b/lib/Model/Project.php @@ -2,7 +2,7 @@ /** * Project * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -1841,11 +1841,11 @@ public function setGallery($gallery) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -1853,12 +1853,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -1883,11 +1883,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ProjectDependencyList.php b/lib/Model/ProjectDependencyList.php index a380219..328c0d2 100644 --- a/lib/Model/ProjectDependencyList.php +++ b/lib/Model/ProjectDependencyList.php @@ -2,7 +2,7 @@ /** * ProjectDependencyList * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -353,11 +353,11 @@ public function setVersions($versions) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -365,12 +365,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -395,11 +395,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ProjectDonationURL.php b/lib/Model/ProjectDonationURL.php index 7b8751b..cf7bd53 100644 --- a/lib/Model/ProjectDonationURL.php +++ b/lib/Model/ProjectDonationURL.php @@ -2,7 +2,7 @@ /** * ProjectDonationURL * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -387,11 +387,11 @@ public function setUrl($url) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -399,12 +399,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -429,11 +429,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ProjectIdentifier.php b/lib/Model/ProjectIdentifier.php index ea36bb4..906c386 100644 --- a/lib/Model/ProjectIdentifier.php +++ b/lib/Model/ProjectIdentifier.php @@ -2,7 +2,7 @@ /** * ProjectIdentifier * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -319,11 +319,11 @@ public function setId($id) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -331,12 +331,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -361,11 +361,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ProjectLicense.php b/lib/Model/ProjectLicense.php index 4a21bbe..a6b9ab6 100644 --- a/lib/Model/ProjectLicense.php +++ b/lib/Model/ProjectLicense.php @@ -2,7 +2,7 @@ /** * ProjectLicense * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -395,11 +395,11 @@ public function setUrl($url) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -407,12 +407,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -437,11 +437,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ProjectResult.php b/lib/Model/ProjectResult.php index 0c2d5fd..6bc4323 100644 --- a/lib/Model/ProjectResult.php +++ b/lib/Model/ProjectResult.php @@ -2,7 +2,7 @@ /** * ProjectResult * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -1280,11 +1280,11 @@ public function setFeaturedGallery($featured_gallery) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -1292,12 +1292,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -1322,11 +1322,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/Report.php b/lib/Model/Report.php index 3b9bc34..a87a3b2 100644 --- a/lib/Model/Report.php +++ b/lib/Model/Report.php @@ -2,7 +2,7 @@ /** * Report * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -651,11 +651,11 @@ public function setThreadId($thread_id) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -663,12 +663,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -693,11 +693,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/Schedule.php b/lib/Model/Schedule.php index 1ff9e9a..5b56a80 100644 --- a/lib/Model/Schedule.php +++ b/lib/Model/Schedule.php @@ -2,7 +2,7 @@ /** * Schedule * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -399,11 +399,11 @@ public function setRequestedStatus($requested_status) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -411,12 +411,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -441,11 +441,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/SearchResults.php b/lib/Model/SearchResults.php index 765e775..714b5cc 100644 --- a/lib/Model/SearchResults.php +++ b/lib/Model/SearchResults.php @@ -2,7 +2,7 @@ /** * SearchResults * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -433,11 +433,11 @@ public function setTotalHits($total_hits) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -445,12 +445,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -475,11 +475,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ServerRenderedProject.php b/lib/Model/ServerRenderedProject.php index e003cb3..52743b2 100644 --- a/lib/Model/ServerRenderedProject.php +++ b/lib/Model/ServerRenderedProject.php @@ -2,7 +2,7 @@ /** * ServerRenderedProject * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -863,11 +863,11 @@ public function setMonetizationStatus($monetization_status) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -875,12 +875,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -905,11 +905,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/Statistics.php b/lib/Model/Statistics.php index a37bfbd..16af843 100644 --- a/lib/Model/Statistics.php +++ b/lib/Model/Statistics.php @@ -2,7 +2,7 @@ /** * Statistics * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -351,7 +351,7 @@ public function getVersions() /** * Sets versions * - * @param int|null $versions Number of projects on Modrinth + * @param int|null $versions Number of versions on Modrinth * * @return self */ @@ -421,11 +421,11 @@ public function setAuthors($authors) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -433,12 +433,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -463,11 +463,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/TeamMember.php b/lib/Model/TeamMember.php index 6a0c971..7c75ae8 100644 --- a/lib/Model/TeamMember.php +++ b/lib/Model/TeamMember.php @@ -2,7 +2,7 @@ /** * TeamMember * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -535,11 +535,11 @@ public function setOrdering($ordering) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -547,12 +547,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -577,11 +577,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/Thread.php b/lib/Model/Thread.php index bf9cf31..86ffc8a 100644 --- a/lib/Model/Thread.php +++ b/lib/Model/Thread.php @@ -2,7 +2,7 @@ /** * Thread * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -551,11 +551,11 @@ public function setMembers($members) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -563,12 +563,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -593,11 +593,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ThreadMessage.php b/lib/Model/ThreadMessage.php index a6726c8..dcb9812 100644 --- a/lib/Model/ThreadMessage.php +++ b/lib/Model/ThreadMessage.php @@ -2,7 +2,7 @@ /** * ThreadMessage * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -437,11 +437,11 @@ public function setCreated($created) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -449,12 +449,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -479,11 +479,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/ThreadMessageBody.php b/lib/Model/ThreadMessageBody.php index dfe95d2..d83a021 100644 --- a/lib/Model/ThreadMessageBody.php +++ b/lib/Model/ThreadMessageBody.php @@ -2,7 +2,7 @@ /** * ThreadMessageBody * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -638,11 +638,11 @@ public function setNewStatus($new_status) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -650,12 +650,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -680,11 +680,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/User.php b/lib/Model/User.php index b04ba9a..787d4b2 100644 --- a/lib/Model/User.php +++ b/lib/Model/User.php @@ -2,7 +2,7 @@ /** * User * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -904,11 +904,11 @@ public function setGithubId($github_id) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -916,12 +916,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -946,11 +946,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/UserIdentifier.php b/lib/Model/UserIdentifier.php index dbfc55a..37d993c 100644 --- a/lib/Model/UserIdentifier.php +++ b/lib/Model/UserIdentifier.php @@ -2,7 +2,7 @@ /** * UserIdentifier * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -322,11 +322,11 @@ public function setUserId($user_id) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -334,12 +334,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -364,11 +364,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/UserPayoutData.php b/lib/Model/UserPayoutData.php index 65d05d0..f7615ee 100644 --- a/lib/Model/UserPayoutData.php +++ b/lib/Model/UserPayoutData.php @@ -2,7 +2,7 @@ /** * UserPayoutData * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -492,11 +492,11 @@ public function setPayoutAddress($payout_address) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -504,12 +504,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -534,11 +534,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/UserPayoutHistory.php b/lib/Model/UserPayoutHistory.php index bd4e6cb..ceb3faf 100644 --- a/lib/Model/UserPayoutHistory.php +++ b/lib/Model/UserPayoutHistory.php @@ -2,7 +2,7 @@ /** * UserPayoutHistory * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -387,11 +387,11 @@ public function setPayouts($payouts) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -399,12 +399,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -429,11 +429,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/UserPayoutHistoryEntry.php b/lib/Model/UserPayoutHistoryEntry.php index 4240208..3bf77bb 100644 --- a/lib/Model/UserPayoutHistoryEntry.php +++ b/lib/Model/UserPayoutHistoryEntry.php @@ -2,7 +2,7 @@ /** * UserPayoutHistoryEntry * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -387,11 +387,11 @@ public function setStatus($status) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -399,12 +399,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -429,11 +429,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/Version.php b/lib/Model/Version.php index e7eb9dd..346b283 100644 --- a/lib/Model/Version.php +++ b/lib/Model/Version.php @@ -2,7 +2,7 @@ /** * Version * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -1038,11 +1038,11 @@ public function setFiles($files) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -1050,12 +1050,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -1080,11 +1080,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/VersionDependency.php b/lib/Model/VersionDependency.php index 7500281..25008e8 100644 --- a/lib/Model/VersionDependency.php +++ b/lib/Model/VersionDependency.php @@ -2,7 +2,7 @@ /** * VersionDependency * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -483,11 +483,11 @@ public function setDependencyType($dependency_type) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -495,12 +495,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -525,11 +525,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/VersionFile.php b/lib/Model/VersionFile.php index caa5995..feccc56 100644 --- a/lib/Model/VersionFile.php +++ b/lib/Model/VersionFile.php @@ -2,7 +2,7 @@ /** * VersionFile * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -545,11 +545,11 @@ public function setFileType($file_type) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -557,12 +557,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -587,11 +587,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/Model/VersionFileHashes.php b/lib/Model/VersionFileHashes.php index 8e23b92..769086b 100644 --- a/lib/Model/VersionFileHashes.php +++ b/lib/Model/VersionFileHashes.php @@ -2,7 +2,7 @@ /** * VersionFileHashes * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -354,11 +354,11 @@ public function setSha1($sha1) /** * Returns true if offset exists. False otherwise. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return boolean */ - public function offsetExists($offset): bool + public function offsetExists(mixed $offset): bool { return isset($this->container[$offset]); } @@ -366,12 +366,12 @@ public function offsetExists($offset): bool /** * Gets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return mixed|null */ #[\ReturnTypeWillChange] - public function offsetGet($offset) + public function offsetGet(mixed $offset) { return $this->container[$offset] ?? null; } @@ -396,11 +396,11 @@ public function offsetSet($offset, $value): void /** * Unsets offset. * - * @param integer $offset Offset + * @param integer|string $offset Offset * * @return void */ - public function offsetUnset($offset): void + public function offsetUnset(mixed $offset): void { unset($this->container[$offset]); } diff --git a/lib/ObjectSerializer.php b/lib/ObjectSerializer.php index 97c4496..d082fcd 100644 --- a/lib/ObjectSerializer.php +++ b/lib/ObjectSerializer.php @@ -2,7 +2,7 @@ /** * ObjectSerializer * - * PHP version 7.4 + * PHP version 8.1 * * @category Class * @package Aternos\ModrinthApi @@ -13,12 +13,12 @@ /** * Labrinth * - * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. ### OAuth2 Applications interacting with an authenticated API should create an OAuth2 application. You can do this in [the developer settings](https://modrinth.com/settings/applications). Make sure to save your application secret, as you will not be able to access it after you leave the page. Once you have created a client, use the following URL to have a user authorize your client: ``` https://modrinth.com/auth/authorize?client_id=&redirect_uri=&scope=++ ``` > You can get a list of all scope names [here](https://github.com/modrinth/code/tree/main/apps/labrinth/src/models/v3/pats.rs). Then, send a `POST` request to the following URL to get the token: ``` https://api.modrinth.com/_internal/oauth/token ``` > Note that you will need to provide your application's secret under the Authorization header. In the body of your request, make sure to include the following: - `code`: The code generated when authorizing your client - `client_id`: Your client ID (found in developer settings) - `redirect_uri`: A valid redirect URI provided in your application's settings - `grant_type`: This will need to be `authorization_code`. If your token request fails for any reason, you will need to get another code from the authorization process. This route will be changed in the future to move the `_internal` part to `v3`. ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
+ * This documentation doesn't provide a way to test our API. In order to facilitate testing, we recommend the following tools: - [cURL](https://curl.se/) (recommended, command-line) - [ReqBIN](https://reqbin.com/) (recommended, online) - [Postman](https://www.postman.com/downloads/) - [Insomnia](https://insomnia.rest/) - Your web browser, if you don't need to send headers or a request body Once you have a working client, you can test that it works by making a `GET` request to `https://staging-api.modrinth.com/`: ```json { \"about\": \"Welcome traveler!\", \"documentation\": \"https://docs.modrinth.com\", \"name\": \"modrinth-labrinth\", \"version\": \"2.7.0\" } ``` If you got a response similar to the one above, you can use the Modrinth API! When you want to go live using the production API, use `api.modrinth.com` instead of `staging-api.modrinth.com`. ## Authentication This API has two options for authentication: personal access tokens and [OAuth2](https://en.wikipedia.org/wiki/OAuth). All tokens are tied to a Modrinth user and use the `Authorization` header of the request. Example: ``` Authorization: mrp_RNtLRSPmGj2pd1v1ubi52nX7TJJM9sznrmwhAuj511oe4t1jAqAQ3D6Wc8Ic ``` You do not need a token for most requests. Generally speaking, only the following types of requests require a token: - those which create data (such as version creation) - those which modify data (such as editing a project) - those which access private data (such as draft projects, notifications, emails, and payout data) Each request requiring authentication has a certain scope. For example, to view the email of the user being requested, the token must have the `USER_READ_EMAIL` scope. You can find the list of available scopes [on GitHub](https://github.com/modrinth/labrinth/blob/master/src/models/pats.rs#L15). Making a request with an invalid scope will return a 401 error. Please note that certain scopes and requests cannot be completed with a personal access token or using OAuth. For example, deleting a user account can only be done through Modrinth's frontend. A detailed guide on OAuth has been published in [Modrinth's technical documentation](https://docs.modrinth.com/guide/oauth). ### Personal access tokens Personal access tokens (PATs) can be generated in from [the user settings](https://modrinth.com/settings/account). ### GitHub tokens For backwards compatibility purposes, some types of GitHub tokens also work for authenticating a user with Modrinth's API, granting all scopes. **We urge any application still using GitHub tokens to start using personal access tokens for security and reliability purposes.** GitHub tokens will cease to function to authenticate with Modrinth's API as soon as version 3 of the API is made generally available. ## Cross-Origin Resource Sharing This API features Cross-Origin Resource Sharing (CORS) implemented in compliance with the [W3C spec](https://www.w3.org/TR/cors/). This allows for cross-domain communication from the browser. All responses have a wildcard same-origin which makes them completely public and accessible to everyone, including any code on any site. ## Identifiers The majority of items you can interact with in the API have a unique eight-digit base62 ID. Projects, versions, users, threads, teams, and reports all use this same way of identifying themselves. Version files use the sha1 or sha512 file hashes as identifiers. Each project and user has a friendlier way of identifying them; slugs and usernames, respectively. While unique IDs are constant, slugs and usernames can change at any moment. If you want to store something in the long term, it is recommended to use the unique ID. ## Ratelimits The API has a ratelimit defined per IP. Limits and remaining amounts are given in the response headers. - `X-Ratelimit-Limit`: the maximum number of requests that can be made in a minute - `X-Ratelimit-Remaining`: the number of requests remaining in the current ratelimit window - `X-Ratelimit-Reset`: the time in seconds until the ratelimit window resets Ratelimits are the same no matter whether you use a token or not. The ratelimit is currently 300 requests per minute. If you have a use case requiring a higher limit, please [contact us](mailto:admin@modrinth.com). ## User Agents To access the Modrinth API, you **must** use provide a uniquely-identifying `User-Agent` header. Providing a user agent that only identifies your HTTP client library (such as \"okhttp/4.9.3\") increases the likelihood that we will block your traffic. It is recommended, but not required, to include contact information in your user agent. This allows us to contact you if we would like a change in your application's behavior without having to block your traffic. - Bad: `User-Agent: okhttp/4.9.3` - Good: `User-Agent: project_name` - Better: `User-Agent: github_username/project_name/1.56.0` - Best: `User-Agent: github_username/project_name/1.56.0 (launcher.com)` or `User-Agent: github_username/project_name/1.56.0 (contact@launcher.com)` ## Versioning Modrinth follows a simple pattern for its API versioning. In the event of a breaking API change, the API version in the URL path is bumped, and migration steps will be published below. When an API is no longer the current one, it will immediately be considered deprecated. No more support will be provided for API versions older than the current one. It will be kept for some time, but this amount of time is not certain. We will exercise various tactics to get people to update their implementation of our API. One example is by adding something like `STOP USING THIS API` to various data returned by the API. Once an API version is completely deprecated, it will permanently return a 410 error. Please ensure your application handles these 410 errors. ### Migrations Inside the following spoiler, you will be able to find all changes between versions of the Modrinth API, accompanied by tips and a guide to migrate applications to newer versions. Here, you can also find changes for [Minotaur](https://github.com/modrinth/minotaur), Modrinth's official Gradle plugin. Major versions of Minotaur directly correspond to major versions of the Modrinth API.
API v1 to API v2 These bullet points cover most changes in the v2 API, but please note that fields containing `mod` in most contexts have been shifted to `project`. For example, in the search route, the field `mod_id` was renamed to `project_id`. - The search route has been moved from `/api/v1/mod` to `/v2/search` - New project fields: `project_type` (may be `mod` or `modpack`), `moderation_message` (which has a `message` and `body`), `gallery` - New search facet: `project_type` - Alphabetical sort removed (it didn't work and is not possible due to limits in MeiliSearch) - New search fields: `project_type`, `gallery` - The gallery field is an array of URLs to images that are part of the project's gallery - The gallery is a new feature which allows the user to upload images showcasing their mod to the CDN which will be displayed on their mod page - Internal change: Any project file uploaded to Modrinth is now validated to make sure it's a valid Minecraft mod, Modpack, etc. - For example, a Forge 1.17 mod with a JAR not containing a mods.toml will not be allowed to be uploaded to Modrinth - In project creation, projects may not upload a mod with no versions to review, however they can be saved as a draft - Similarly, for version creation, a version may not be uploaded without any files - Donation URLs have been enabled - New project status: `archived`. Projects with this status do not appear in search - Tags (such as categories, loaders) now have icons (SVGs) and specific project types attached - Dependencies have been wiped and replaced with a new system - Notifications now have a `type` field, such as `project_update` Along with this, project subroutes (such as `/v2/project/{id}/version`) now allow the slug to be used as the ID. This is also the case with user routes.
Minotaur v1 to Minotaur v2 Minotaur 2.x introduced a few breaking changes to how your buildscript is formatted. First, instead of registering your own `publishModrinth` task, Minotaur now automatically creates a `modrinth` task. As such, you can replace the `task publishModrinth(type: TaskModrinthUpload) {` line with just `modrinth {`. To declare supported Minecraft versions and mod loaders, the `gameVersions` and `loaders` arrays must now be used. The syntax for these are pretty self-explanatory. Instead of using `releaseType`, you must now use `versionType`. This was actually changed in v1.2.0, but very few buildscripts have moved on from v1.1.0. Dependencies have been changed to a special DSL. Create a `dependencies` block within the `modrinth` block, and then use `scope.type(\"project/version\")`. For example, `required.project(\"fabric-api\")` adds a required project dependency on Fabric API. You may now use the slug anywhere that a project ID was previously required.
* - * The version of the OpenAPI document: v2.7.0/15cf3fc + * The version of the OpenAPI document: v2.7.0/366f528 * Contact: support@modrinth.com * Generated by: https://openapi-generator.tech - * Generator version: 7.11.0 + * Generator version: 7.17.0 */ /** @@ -324,24 +324,6 @@ public static function toHeaderValue($value) return self::toString($value); } - /** - * Take value and turn it into a string suitable for inclusion in - * the http body (form parameter). If it's a string, pass through unchanged - * If it's a datetime object, format it in ISO8601 - * - * @param string|\SplFileObject $value the value of the form parameter - * - * @return string the form string - */ - public static function toFormValue($value) - { - if ($value instanceof \SplFileObject) { - return $value->getRealPath(); - } else { - return self::toString($value); - } - } - /** * Take value and turn it into a string suitable for inclusion in * the parameter. If it's a string, pass through unchanged @@ -613,6 +595,6 @@ public static function buildQuery(array $params, $encoding = PHP_QUERY_RFC3986): } } - return $qs ? (string) substr($qs, 0, -1) : ''; + return $qs ? substr($qs, 0, -1) : ''; } }