Documentation Index
Fetch the complete documentation index at: https://apidocs.erlc.gg/llms.txt
Use this file to discover all available pages before exploring further.
Please note: Global API keys are intended for applications running at a large scale, we look to ensure that there are at least 100+ ER:LC private servers using your app.
What is a global API key?
Instead of being identified by IP, your requests are identified by yourAuthorization header. This allows ER:LC to grant your application higher rate limits regardless of the IP it runs on.
When to request one
You should consider requesting a global API key when your application is regularly hitting rate limits under normal operation and you have already implemented proper caching, backoff logic, and rate limit header handling.How to request a global API key
Open a ER:LC API ticket in the ER:LC Discord server. Your request must include all of the following, or it will not be reviewed:- Your service’s name and a link to a website that describes it (a Discord server invite is acceptable if you do not have a website)
- A list of ER:LC-related features provided by your service
- The number of unique ER:LC private servers that use your ER:LC integrations
- A brief summary of how you currently handle rate limits from the PRC API
- The reason you are requesting a global API key
Requirements for approval
To be considered for a global API key, your service must:- Be available 24/7 with minimal downtime
- Be scalable, well-maintained, and consistently stable (few bugs or operational issues)
- Fully use the
/v2/API- Clients may continue to use v1 APIs that are not available in v2.
Large app guidelines
If your application holds a global API key, the following guidelines apply in addition to the standard API Use Guidelines. These requirements exist to protect platform integrity and the broader ER:LC community. 1. Monitoring and alerting You must have internal monitoring and alerting in place for API errors, rate limits, and latency. If you detect recurring issues or API degradation, proactively notify PRC Support before the problem escalates. 2. Rate limit compliance Large apps must actively monitor their rate usage and stay well within their allocated limits, as provided in response headers. 3. Caching and optimization Use caching where appropriate to reduce unnecessary API calls. Do not make requests for data you already have or that has not changed since your last fetch. 4. Responsible support use Only developers with knowledge of your system’s internals should contact us for API support. Do not direct your end users to ER:LC for help — have a developer on your team contact ER:LC with full issue details. 5. User misattribution Do not imply that your application is an official ER:LC product. Clearly indicate to your users that your app is a third-party integration and provide your own support channels. 6. Issue communication If your app becomes non-functional for end users due to a known issue, post a public status update or in-app message where possible. You must promptly notify us if any of the following occur:- A data breach affecting users of the API
- Unauthorized access to your API key or credentials
- Abuse of your integration to bypass rate limits or exploit platform behaviour
- Any security vulnerability that could affect ER:LC systems or users
Reset a global API key
If your global key is compromised, reset it by sending aPOST to /v1/api-key/reset with your current key in the Authorization header. The response contains a new key — you can only view it once. If you lose it, the person who originally requested the key must contact PRC to have it reissued.
cURL