Beginning Jan 1st, 2025, usage of the old API domain of api.mod.io will heavily restricted, and all API usage should be using the new API domain --parse_apiurl which can be found via your games dashboard or on your API access page.
Beginning Jan 1st, 2024, the error ref --parse_errorref_RATE_LIMITED_ENDPOINT will be returned when a rate limit applies only to the endpoint being called. Error ref --parse_errorref_RATE_LIMITED_GLOBAL will continue to be returned in all other scenarios where the rate limit applies to all endpoints.
Beginning Nov 20th, 2022, all custom rate limit headers X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-RetryAfter will no longer be returned. They will be replaced with retry-after when the ratelimit is exceeded.
Our aim with --parse_sitename is to offer developers the most powerful and flexible mod API available. This means continually evolving and improving based on your requirements and pushing changes when required. The majority of these changes will be non-breaking and deployed immediately, however there will be times when breaking changes are needed. To ensure your --parse_sitename implementations are not affected by the changes, we have architectured a versioning system that aims to maintain backwards compatibility and allow you to upgrade your implementation at a time that suits.
Upon first look, our implementation is consistent with many other REST API's, where you have a version specified in the URL and can change that value as required. The --parse_sitename API follows this convention - however, we don't treat our versions as 'major' and instead we release a new version each time breaking changes are made. This allows us to release updates as frequently as is deemed required, with no impact on existing API consumers. Documentation is also preserved for past versions, so whilst we recommend you use the latest version of the API, we will always aim to support legacy versions.
For the initial release of the API, v1 is a valid format and version. Future releases will continue to follow this convention, by incrementing the version number, i.e. v[0-9]+
v1- Initial version of our API.v2- The next major release of the API, that will require a migration to support the breaking changes made to the prior version.v9- The 9th release of the API, that will require a migration to support the breaking changes made to the prior version.
Example cURL request
---------------------
curl -X GET --parse_apiurl/games?api_key=YourApiKeyWhen you make a request, setting the version of --parse_sitename is a requirement as it forms part of the URL required to make a successful request.
When making requests to the API, you need to be sure you know what functionality is available to you
and what you can expect the API to do under every situation. With that said, and in the interest of
being as explicit as possible if you supply a version in the URL of your request that is not listed
in the changelog below - a 404 Not Found will be returned in the form of the Error Object.
The benefit of the approach we have taken to versioning, is it allows us to push breaking changes and continually improve the API without impacting your application until you update. To clarify, for the --parse_sitename API the following are what constitutes as breaking changes:
| Non-Breaking (not covered in changelog) | Breaking Changes |
|---|---|
| Adding new fields to an object | Modifying or removing a field in an object |
| Adding new events | Modifying or removing an endpoint's path |
| Adding new objects to a response | Modifying any HTTP code that could returned by a request |
| Adding new headers to a request/response | Modifying any HTTP error code that could returned by any endpoint |
| Changing the ordering of items in a response | Modifying or removing any request/response header |
Changes that are non-breaking will continue to be delivered to you regardless of which API version you are using, and documentation for every version will continue to be updated to reflect these changes. Only breaking changes described above will fall under this versioning system.