name: Veracode API Rate Limits
specification: API Commons Rate Limits
specificationVersion: '0.1'
schema: https://raw.githubusercontent.com/api-evangelist/interface-research/main/schema/api-commons.yml#/$defs/RateLimits
provider: Veracode
providerId: veracode
created: '2026-05-04'
# Provenance stamped 2026-08-11: this artifact was written by the API Evangelist
# bulk sweep dated 2026-05-04, not harvested from the provider. See roadmap#35.
method: generated
modified: '2026-05-05'
reconciled: true
tags:
  - Application Security
  - SAST
  - DAST
  - SCA
  - DevSecOps
  - Rate Limiting
description: 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.
sources:
  - https://docs.veracode.com/r/About_Veracode_API_Best_Practices
  - https://docs.veracode.com/r/c_rest_intro
headers:
  retryAfter: retry-after
responseCodes:
  throttled: 429
limits:
  - name: Status-check polling minimum interval
    scope: account
    metric: requests_per_minute
    limit: 1 every 2 minutes (recommended minimum spacing for status polls)
    notes: Veracode best practices mandate at least two minutes between status check calls; excessive
      polling will be throttled.
  - name: General API throttling threshold
    scope: account
    metric: varies
    limit: not numerically published; throttling engages when polling / call rate is excessive
    notes: Veracode does not publish a global RPS / RPM ceiling; throttle behavior is account-scoped.
policies:
  - name: Honor retry-after on 429
    description: On HTTP 429, clients must read the retry-after header and wait at least that long before
      retrying.
  - name: Five-retry maximum
    description: Veracode best practices cap retries at five attempts to handle transient network issues;
      beyond that, fail and surface the error.
  - name: Use Reporting / Findings APIs for bulk pulls
    description: 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.
  - name: Use service accounts
    description: 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.
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com
    url: https://apievangelist.com