Veracode · Rate Limits
Veracode Rate Limits
Veracode does not publish numeric per-second / per-minute API rate limits, but documents concrete throttling and retry guidance in its API Best Practices. Excessive polling triggers throttling; HTTP 429 is returned with a retry-after header. Veracode also publishes operational guidance (minimum poll interval, retry budget) that consumers must follow to stay below the throttle threshold.
2 Limits
Throttle: 429
Application SecuritySASTDASTSCADevSecOpsRate Limiting
Limits
Status-check polling minimum interval account
1 every 2 minutes (recommended minimum spacing for status polls)
Veracode best practices mandate at least two minutes between status check calls; excessive polling will be throttled.
General API throttling threshold account
not numerically published; throttling engages when polling / call rate is excessive
Veracode does not publish a global RPS / RPM ceiling; throttle behavior is account-scoped.
Policies
Honor retry-after on 429
On HTTP 429, clients must read the retry-after header and wait at least that long before retrying.
Five-retry maximum
Veracode best practices cap retries at five attempts to handle transient network issues; beyond that, fail and surface the error.
Use Reporting / Findings APIs for bulk pulls
For large-scale data retrieval, use the Reporting API rather than polling per-application endpoints; for near real-time per-app data, use the Findings or Summary Report REST APIs.
Use service accounts
Automations should run under API service accounts (with the dedicated API role), not under user accounts; credentials expire after 365 days and must be rotated.