REST API Throttle Limits (HTTP 429 Response Code)

Published Date: January 2, 2026
Validated: Yes
Audience: Everyone
Products and Versions Covered:

• Jama Connect® (all supported versions)
• Cloud / CVC

Summary

This article explains Jama Connect® REST API throttle limits, why HTTP 429 responses occur, and how to handle them effectively.

Jama Connect provides a robust REST API that supports high-volume usage (tens of millions of calls per environment per month). To maintain system performance and ensure a consistent experience for all users, API requests are rate-limited.

When the request rate exceeds the allowed threshold, Jama Connect returns an HTTP 429 (Too Many Requests)response. This response indicates that the client must reduce request frequency and retry the request after a delay.

Proper handling of 429 responses is essential. Scripts or integrations that do not account for throttling may fail to complete operations or negatively impact system performance.

IMPORTANT:
Access to the REST API is limited to users with a Named Creator Jama Connect license, including access to v1, labs, and SCIM endpoints. Users without a Named Creator license, including those with a Creator Float License, do not have access.

Resolution

Understand Throttle Limits

• Jama Connect enforces a limit of 10 API calls per second per environment
• This limit distributes system load and prevents performance degradation
• Throttling is applied dynamically when the request volume exceeds this threshold

Identify a Throttled Request

When throttling occurs:

• The API returns an HTTP 429 response code
• This signals that the client should pause and retry the request

Implement Proper Retry Logic

To ensure reliability, all API scripts and integrations must handle 429 responses.

1. Detect the HTTP 429 response code
2. Pause execution before retrying the request
3. Retry the request after a delay
4. Continue retrying until the request succeeds or a defined retry limit is reached

Use Exponential Backoff (Recommended)

Jama recommends implementing exponential backoff to manage retries efficiently.

Example retry pattern:

• Wait 3 seconds → retry
• Wait 5 seconds → retry
• Wait 8 seconds → retry
• Wait 13 seconds → retry

This approach:

• Reduces repeated throttling
• Distributes API load over time
• Improves overall success rates for high-volume operations

Design for Scalable API Usage

To prevent throttling issues:

• Spread API calls over time instead of sending bursts
• Avoid unnecessary or duplicate requests
• Batch operations where possible
• Monitor API usage patterns in integrations

Scripts that do not follow these practices may:

• Fail to complete operations
• Experience repeated throttling
• Impact overall system performance

IMPORTANT: Access to the REST API is limited to users with a Named Creator Jama Connect license, including access to v1, labs, and SCIM endpoints. Users without a Named Creator Jama Connect license, including those with a Creator Float License, do not have access.

Additional References

• REST API Documentation
• REST API Access Control
• Sample API Calls
• Request an API Consultation (requires a Success Program)
• Implement retries with exponential backoff - .NET

Feedback

We welcome your input! Please sign in to leave comments, suggestions, or ideas for improvement below.