Skip to main content
Plan your integration around the following request and computation limits.

​
Integration limits

Keep traffic within all three read-rate limits. Staying below 60 requests per minute does not allow you to exceed the hourly or daily limit. The burst allowance limits simultaneous requests; it does not increase those request budgets. Import inspect has its own request limit. Compute jobs also have separate concurrency and daily limits: wait for a running job to finish before starting another if five are already in progress.

​
Handle a rate-limit response

A throttled request returns HTTP 429 Too Many Requests. Pause requests rather than retrying immediately.
  • If the response includes a Retry-After header, wait for the indicated interval or time before retrying.
  • If Retry-After is absent, use exponential backoff with jitter: increase the delay between retries and add a small random delay so clients do not all retry together. Limit the number of retries.
  • Reduce polling frequency and the number of concurrent requests if throttling continues. A short retry delay does not replenish an exhausted daily budget.
Retry reads after the delay. Before resubmitting a job or an import whose outcome is uncertain, check whether it was already accepted to avoid duplicate work.

​
Keep your integration within the limits

  • Spread requests over time instead of sending large bursts.
  • Reuse retrieved data when it is still suitable for your workflow.
  • Use pagination and filters to retrieve only the records you need.
  • Track running jobs and reuse their results instead of repeatedly submitting the same computation.
If these limits prevent your integration from working as intended, contact api@valar.space with the endpoints, expected request volume, and number of concurrent jobs you need.