Skip to main content
The API is rate-limited on two rolling windows: requests per minute (RPM) and requests per hour (RPH). Limits are per-organization — every credential in an org (personal API keys and OAuth tokens alike) draws from one shared bucket. Adding more keys does not raise your throughput.

​
Defaults

WindowDefault
Per minute60 requests
Per hour1,000 requests
Limits are configurable per organization by Awardee staff. To request a higher ceiling, contact [email protected] with your expected traffic profile and a brief use case.

​
Response headers

Every response (success or failure) carries the rate-limit headers for both windows: 
X-RateLimit-Limit-Minute: 60
X-RateLimit-Remaining-Minute: 17
X-RateLimit-Reset-Minute: 1716461700
X-RateLimit-Limit-Hour: 1000
X-RateLimit-Remaining-Hour: 873
X-RateLimit-Reset-Hour: 1716465300
  • Limit-* is the cap for that window.
  • Remaining-* is how many requests the org has left.
  • Reset-* is the Unix timestamp (seconds) at which the window rolls over.
Inspect Remaining-* proactively to slow down before you hit the cap, rather than reacting to 429s after the fact. Because the bucket is shared, the value reflects traffic from every credential in the org.

​
Hitting a cap

When you exceed either window, you get 429 rate_limited. The response includes a standard Retry-After header (in seconds) alongside the per-window rate-limit headers: 
HTTP/1.1 429 Too Many Requests
Retry-After: 27
X-Request-Id: req_8fK2x9aLp0qR
X-RateLimit-Limit-Minute: 60
X-RateLimit-Remaining-Minute: 0
X-RateLimit-Reset-Minute: 1716461727
X-RateLimit-Limit-Hour: 1000
X-RateLimit-Remaining-Hour: 412
X-RateLimit-Reset-Hour: 1716465300

{
  "error": "rate_limited",
  "message": "Rate limit exceeded.",
  "request_id": "req_8fK2x9aLp0qR"
}
Read Retry-After to know exactly how long to wait. The remaining count for each window tells you which limit you hit — a burst trips the minute window (Remaining-Minute: 0) while sustained over-quota drains the hour window.

​
Backoff strategy

1

Honor Retry-After

On a 429, sleep for at least the number of seconds in the Retry-After header before retrying. Do not retry sooner — you will just consume your quota faster as it refills.
2

Add jitter

Add up to 500ms of random jitter so concurrent workers don’t synchronize their retries.
3

Exponential backoff on repeats

If a second 429 follows the first, double the next sleep. If a third follows, double again. Cap the backoff at 60 seconds.
4

Give up after a few attempts

Three retries is usually enough. A fourth 429 means you’re sustaining above quota, not glitching — surface the failure and slow your producer.
async function withBackoff(request, attempts = 4) {
  let delayMs = 0
  for (let i = 0; i < attempts; i++) {
    if (delayMs > 0) {
      await new Promise((r) => setTimeout(r, delayMs + Math.random() * 500))
    }
    const res = await request()
    if (res.status !== 429) return res
    const retryAfter = Number(res.headers.get("Retry-After")) || 1
    delayMs = Math.min(retryAfter * 1000 * 2 ** i, 60_000)
  }
  throw new Error("Rate-limited after retries")
}
Most HTTP clients have a built-in retry adapter — axios-retry, urllib3.util.Retry, Go’s retryablehttp. Configure it to retry only on 429 and honor Retry-After. Do not also retry on 5xx without idempotency keys, or you risk creating duplicates.

​
Burst vs sustained

The minute window absorbs short bursts. If your average is well under 1,000/hour but you batch 60 requests in five seconds, you’ll briefly hit the minute cap. Spread POSTs across the minute, or use the Idempotency header so retries are safe. The hour window protects against sustained over-quota. If you’re hitting it regularly, the integration’s request profile is wrong for the current limits — either reduce the rate or request a raise.

​
One bucket per org

All of an organization’s credentials share the same counters. If one process saturates the minute cap, every other credential in the org — including OAuth tokens — sees 429s until the window resets. Minting additional keys will not give you more throughput; it only changes how traffic is attributed, not how much is allowed. To scale, either smooth your request rate or ask support to raise the org’s limits.