Raster

Rate limits

The RateLimit response headers, the 429 response, and how to pace an integration or an agent against the Raster REST API.

Every REST response carries its quota state in the standard RateLimit header fields. Read them on the responses you already receive and pace against them.

Response headers

RateLimit-Policy is present on every response, including 4xx and 5xx. RateLimit is present on every credentialed response.

HeaderExampleMeaning
RateLimit-Policy"key";q=600;w=60The quota (q) and window length in seconds (w) being applied.
RateLimit"key";r=412;t=37Requests left (r) and seconds until the window resets (t).

The widely-deployed RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset headers are sent alongside them, carrying the same numbers.

t and RateLimit-Reset are a number of seconds from now.

Quotas

PolicyCounted againstAllowance
keyThe Authorization credential600 per 60 seconds
ipClient IP, for anonymous calls such as POST /libraries60 per 60 seconds

The reported allowance is a floor: the API runs across several instances and each counts its own window, so the aggregate allowance is at least what the header reports. A client that paces against the header stays inside the quota.

The key policy is the one that answers 429 below, and the only one that reports a running RateLimit. An anonymous request receives RateLimit-Policy alone: its traffic is counted at the network edge, which sees the real client address, so a per-request remaining count here would always read full.

When you exceed the limit

A request over the allowance returns 429 with Retry-After and the standard error envelope:

HTTP/1.1 429 Too Many Requests
Retry-After: 23
RateLimit-Policy: "key";q=600;w=60
RateLimit: "key";r=0;t=23
Content-Type: application/json

{
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Rate limit exceeded. Retry after the number of seconds in Retry-After."
  }
}

Full definition of the code: RATE_LIMIT_EXCEEDED.

Pacing an integration

  • Wait the number of seconds in Retry-After. It is exact.
  • Slow down as r falls. Below roughly 10% of the policy's q, spread the rest of your calls over t seconds.
  • Back off exponentially on repeated 429s, with jitter so parallel workers retry at different moments.
  • Batch instead of looping. Tagging, untagging, transferring, and deleting each accept many asset ids per call, which costs one unit of quota.
  • Poll at an interval. Upload processing continues after the response; re-fetch the asset every few seconds rather than continuously.

On this page