429 Too Many Requests response and you must wait until the next minute window before making additional requests.
Limits by tier
| Account tier | Requests per minute |
|---|---|
| Free | 60 |
| Researcher Pro/Enterprise | 180 |
If your use case regularly approaches the Free limit (such as scanning large dependency graphs in CI or running a continuously updated security dashboard) consider upgrading to a paid account to get 180 requests per minute. Please note, this is only for organizations at this time. Paid accounts are not available for individuals. Contact us to learn more.
What happens when you exceed the limit
When you send more requests than your tier allows within a one-minute window, the API responds with:- HTTP status:
429 Too Many Requests - Body: a JSON object explaining the error
Best practices for staying within limits
Cache results
Cache results
Threat data for a given resource does not change frequently. Cache the response from
check-malicious locally (for example, for 24 hours) so you do not repeat identical lookups. This is especially effective in CI/CD pipelines where the same dependency list is scanned on every build.Stagger automation
Stagger automation
For automation that runs on a schedule (nightly scans, for example), spread requests evenly across the minute window rather than firing them all at once. A small
sleep between requests keeps you well within your quota without sacrificing throughput.Use exponential backoff on 429
Use exponential backoff on 429
When you receive a
429, wait before retrying rather than retrying immediately. A simple exponential backoff strategy (wait 1 second, then 2, then 4, capping at a maximum) prevents a burst of retries from compounding the problem.Batch lookups where possible
Batch lookups where possible
If you’re scanning a dependency list, deduplicate it before sending requests. Checking the same package multiple times in a single scan wastes quota. Sort and deduplicate your input list before the scan loop.

