Rate Limits

GitScrum API rate limits and throttling. Understand request quotas and how to handle 429 responses.

REST API — All endpoints require authentication via Bearer token. Include Authorization: Bearer {token} in every request. Tokens are managed in GitScrum Settings → API. Base URL: https://services.gitscrum.com — All request paths in this documentation are relative to this base URL.

The GitScrum API enforces rate limits to ensure fair usage and platform stability.

Default limits

Limit	Value
Requests per minute	60
Scope	Per token

Response headers

Every API response includes rate limit headers:

Header	Description
`X-RateLimit-Limit`	Maximum requests allowed per window
`X-RateLimit-Remaining`	Requests remaining in the current window
`X-RateLimit-Reset`	Unix timestamp when the window resets

Example headers

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1738900800

429 Too Many Requests

When you exceed the rate limit, the API returns 429:

{
  "error": "Too Many Requests",
  "message": "Rate limit exceeded. Retry after 32 seconds.",
  "retry_after": 32
}

The Retry-After header indicates how many seconds to wait before retrying.

Handling rate limits

Exponential backoff

Implement exponential backoff when you receive a 429 response:

# Pseudocode
wait = 1
while response.status == 429:
  sleep(wait)
  wait = wait * 2
  retry request

Monitor headers

Check X-RateLimit-Remaining before making requests. Pause or slow down when the value approaches zero.

Best practices

Cache responses — Avoid repeated identical requests. Cache workspace, project, and workflow data locally.
Batch operations — Group related changes instead of making individual calls.
Use webhooks — Subscribe to events instead of polling for changes.
Respect Retry-After — Always honor the Retry-After header value before retrying.
Spread requests — Distribute API calls evenly over time rather than bursting.