To prevent misuse of our systems we have implemented sophisticated AI powered software that secures our website. One factor this software uses is API request and server ping rate limits.
Our software monitors all API requests and server pings 24/7 and looks for abuse. If your app is found abusing our system, whether intentional or otherwise, it could result in failure messages or worse.
For these reasons it’s very important to build your API calls with rate limits in mind.
How Rate Limiting Works #
While we cannot give away any specific details about our rate limiting security system, we can say for certain that if an end user checks keys too fast, whether the fault of the user or the code, that end user will be timed out and not allowed to preform any more key checks until the timeout is over. This will also happen if the end user, or your code, pings our servers too much or too quickly.
NOTE: To protect your account and good faith end users as much as possible we set these limits on a per end user basis. They are not based on your BatchKeys account.
Therefore, even if multiple malicious end users are abusing your app at the same time the rest of your users can still check their keys and use your app without issue.
Repeatedly sending API requests or pings after being timed out will increase these timeout durations. This duration will eventually reset on its own when our security system decides it is safe to do so.
In a worst case scenario where an end user, or your code, continues to send requests or pings after being timed out multiple extended times they will be indefinitely blacklisted from connecting to our services. Depending on how you integrate key checking, this can prevent the end user from using your app so its very important to keep rate limits in mind when building your API calls.
Additionally, poorly coded legitimate apps or malicious tools specifically designed to encourage end users to bulk check keys or check single keys too fast are not allowed and may be banned from using our services.
Ping Rate Limits #
Our ping rate limiter acts similar to our API rate limiter. If your app pings our services too often, the end user may be blacklisted and prevented from connecting to our servers permanently. Depending on how you integrate pings, this can prevent the end user from using your app.
End User Rate Limit Issues #
End users may not always act as expected, but they can be grouped into three classes for the purposes of this discussion. Good faith, malicious, and accidentally malicious.
Ideally an end user should never even know a rate limit system exists, and that’s how we have designed our AI security system. With that in mind, our rate limiting system is generous to good faith end users. It always assume the end user is acting in good faith until proven otherwise.
Good Faith End Users #
A normal, good faith end user hitting a rate limit is not malicious and likely indicates they are having real issues that we should proactively try to prevent. This almost always entails simple issues while entering a key into a form, such as a failure to copy and paste it properly, or they believed the hyphens should be removed, etc.
These simple issues are already handled by our security system and return appropriate error messages in the JSON header for developers to do with as they need. Good faith end users are given many tries to produce a valid key, their timeouts are short, and timeouts will automatically end after an equally short amount of time so that they can try again later.
Malicious End Users #
A malicious end user is only trying to steal your app, usually by cracking the key through various methods. These are the end users we maximize rate limiting on and blacklist as soon as they are identified. We also ask you to guard against malicious users on your end as best you can.
Accidentally Malicious End Users #
There are also accidentally malicious end users, they’re usually a good faith end user doing something unexpected or strange. For instance, if you’ve released a batch of keys publicly for an event and a single end user finds them they might naturally decide to check every key until they find a successful one. This could trigger rate limiting if they check them too quickly.
However we find that such issues quickly resolve themselves if the end user is acting in good faith and our security systems are more than capable of handling them.
Preventing End User Issues #
The simplest way to prevent good faith end user timeouts is to clearly display what a key should look like in the input field with a placeholder dummy key, such as the following:
Kh7B10E-MjGn45q-Ab74STC-Df29p7R-sIj60A4This key will always fail and is safe to use for such purposes. We find that this solves 99% of key input errors.
A more nuanced solution is to design your app in such a way to deliver and prefill the correct key automatically for each user based on their unique identifying information from the purchase, such as their billing email address or username.
You could also display a simple message about trying keys slowly, however this isn’t strictly necessary as any good faith end user only wishes to try their key once anyways, plus the user will receive a similar error message on their first timeout (assuming you are displaying the API’s response messages).
To prevent malicious users we highly recommend adding a honeypot (a hidden field only bots can see that a normal user would never actually submit) or using a captcha service like hCaptcha or reCaptcha to the form you use to check license keys with.
Resolving End User Abuse #
If good faith end users are found to be abusing our systems we ask that you manage your users by implementing the above suggestions and prevent them from further abusing the system to the best of your ability.
If malicious end users are found to be abusing our services specifically through your app we ask that you work with us in a timely manner to circumvent such abuse. For example, you could add captchas or honeypots to forms that use our API, or make additional security checks that validate additional information only available to us before sending API requests.
Most importantly, do not post your keys publicly. Keep them secret and hidden. Please read our documentation on preventing abuse and securing your keys for more info.
Unbanning A Valid End User #
End user bans are handled by our AI security system and must be manually restored by us. See our documentation on unbanning end users, including how to whitelist certain end users (Enterprise plans only).
Code Related Issues #
We understand it’s easy to accidentally create bad logic in code without realizing it. That’s why it’s so important to design your code with API request best practices in mind. Here are a few rules to keep in mind:
Don’ts:
- Do not check keys on a repeatable event like every X timeframe, or every page load, or every scene change, etc.
- Do not continuously ping our servers to check internet connections.
- Do not continuously recheck failed responses until a successful key check occurs.
Do’s:
- Use a special pinging service or ping a large domain such as google.com to check generic internet connectivity.
- Check the end user’s internet connectivity once via a simple ping when the app starts.
- Only check a currently active key once when the app starts.
- Check new keys on single fire events only, such as a form submission or software install.
- Only ping our servers on single fire events that have no choice but to do so.
- Have fallbacks in place, such as saving previous key check results in an encrypted local file in case of end user internet connectivity issues.
- Consider bypassing key checks if the end user has no internet connectivity (poses a security risk if the key has never been checked).
- Have a catch-all generic fallback measure in place for key check event failures caused by unknown reasons.
These are all standard practices with API calls and we understand that you likely knew all of this already, but they must be emphasized.
Preventing Code Issues #
When designing your functions always avoid API requests that are based on recurring events, and instead only make API requests on single firing events. If an event fails or an error is returned it might be a good idea to run it again, but avoid multiple rechecks in a short timeframe and do not continuously check until a success message is found.
Consider pinging a service to ensure internet connectivity before checking keys and have fallback measures in place. It’s also a good practice to have generic fallback measures for “if all else fails” situations, such as asking an end user to contact your support team or perhaps allowing the app to run for a period of time before rechecking (and then finally failing to run after subsequent checks fail).
Ping Related Issues #
Bans related to pings are almost always code errors or bad code logic. To ensure you’re not pinging our servers too much only use single fire events to send pings, such as when your app launches.
If you need to ping often, like to check if an end user’s internet connection has been dropped, either ping a large domain such as google.com to check for an internet connection or use a service made exclusively for pinging.
If you build a function that must ping our servers specifically and there is no other way to run the logic, such as simply pinging google.com, ensure it:
- Limits pings to https://batchkeys.com only
- Limits pings to less than once every 10 minutes
Failure to do so can get your end users blacklisted in our system. For detailed documentation on how to properly use pings please see our full documentation on dealing with connection errors and rechecks.
Resolving Code Issues #
As we said before, we understand it’s easy to accidentally create bad code logic and we’re generous in resolving such issues. If we detect your app is making unusual requests or if your app is specifically being rate limited too much above others, we will ask that you fix the underlying code issues in a timely manner. Otherwise you could face a temporary suspension or permanent deletion of your account. This will prevent your keys from working.