Stay under source host API limits by replacing polling with webhooks, using conditional requests so unchanged data is cheap, funnelling calls through one rate-aware queue, and honouring retry and reset headers. Budget calls per repository before you scale, because limits are shared across everything using the same credential.
What the limits look like
GitHub documents both a primary and a secondary rate limit for its REST API. Authenticated users get 5,000 requests per hour, and apps owned by an enterprise organisation get higher limits. Secondary limits also apply: GitHub says no more than 100 concurrent requests are allowed, and it cautions against too much CPU time per minute. Your own host will differ, so read its documentation and treat any number here as an example, not a rule.
The main lesson is that a scanner is a heavy API client. Listing repositories, fetching manifests, reading pull request metadata and posting comments all count. At a few thousand repositories, naive polling uses the whole budget before a single scan runs.
Techniques that cut request counts
| Technique | Effect |
|---|---|
| Webhooks instead of polling | GitHub's guidance is to subscribe to events rather than poll. You only call when something changed. |
| Conditional requests | Send the stored ETag. A 304 Not Modified response does not count against the primary limit for authenticated requests, per GitHub's documentation. |
| Clone or archive once | Fetching a repository archive is often cheaper than many file-level API calls. |
| Request only what you need | Smaller, stable responses cache better. |
| Spread over time | Scheduled rescans should be jittered, not all at the top of the hour. |
Build a rate-aware client
- Route every call to the source host through one component, so the budget is tracked in one place.
- Read the remaining and reset headers on each response and slow down before you hit zero.
- If a response includes a retry-after header, wait at least that long. GitHub says not to retry before then, and if the remaining count is zero, wait until the reset time.
- On repeated secondary limit errors, back off exponentially and give up after a set number of tries.
- Make requests serially where you can. GitHub's own guidance suggests a queue to avoid concurrent bursts, and a pause of at least one second between mutating calls such as posting comments.
- Use separate credentials, such as an app installation per organisation, so one busy tenant does not exhaust everyone.
Common mistakes
Retrying immediately after a limit error makes things worse, and GitHub notes that continuing to make requests while limited can get an integration banned. Another mistake is sharing one personal token across all scanning, which also drains the budget of the human who owns it.
Posting a comment for every finding is another trap. Aggregate into one summary comment or one check run per pull request.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that the inventory is built once and reused, which is the same idea that keeps source host calls low.
Safeguard connects to your repositories to produce SBOMs and dependency findings, and you can see what a scan returns with the free scan at https://gold.safeguard.sh/scan.
Quick check
Do conditional requests really save budget?
For authenticated requests, GitHub's guidance says unchanged data returned as 304 does not count against the primary rate limit. Check your own host for the equivalent rule.
Is a bigger rate limit the fix?
It helps, but request volume that scales with repository count will eventually outgrow any limit. Reduce calls first.
Sources
Last reviewed: 19 October 2026.
