Table of Contents

GraphQL Rate Limiting Overview

Jennifer Trower Updated by Jennifer Trower

Read Time: 4 mins

We're currently reviewing our approach to rate limiting and temporarily pausing our existing plan while we evaluate next steps.

GraphQL rate limiting is a control mechanism introduced by Sonar to manage the number of API requests a user can make in a given time frame. This approach supports fair usage, protects backend systems, and ensures a consistent experience for all users. As usage patterns grow in complexity across clients, scalable management of system resources becomes increasingly important.

What Is GraphQL Rate Limiting?

Rate limiting defines the number of API requests a user can make within a specific timeframe. In Sonar’s GraphQL API, each user is allowed up to 400 requests per minute. When this limit is exceeded, additional requests are blocked and a clear error response is returned. The counter resets every 60 seconds, allowing request flow to resume normally once a new interval begins.

Example of an error response: {"error": "Request limit of 400/min reached."}

Why Rate Limiting Is Important

Rate limiting plays a key role in maintaining the health and reliability of the Sonar platform. It helps prevent backend systems from becoming overwhelmed by high volumes of traffic, particularly from misconfigured or overly aggressive scripts. By setting clear usage thresholds, it ensures that no single user can disrupt the experience for others, especially in shared environments. These transparent limits guide users toward responsible API usage and support efficient integration practices. Overall, rate limiting is a critical part of Sonar’s broader effort to build a scalable, high-performance platform.

How Limits Were Determined and What to Expect

The current rate limits were established based on an extensive review of actual client usage data. By analyzing real-world traffic patterns, Sonar aimed to define limits that maintain platform stability without disrupting typical user workflows. These limits are part of a phased strategy, with the intent to gradually lower thresholds over time to ensure long-term sustainability, while preserving a positive customer experience.

Upcoming limit reductions will be carefully monitored and tested after regular business hours (starting at 5:00 PM PST). If any issues arise—such as legitimate users hitting limits unexpectedly—Sonar is prepared to reverse changes or apply custom per-instance limits as needed to ensure minimal disruption.

This rate-limiting strategy complements the GraphQL query complexity limits introduced last year. While complexity limits act as a safeguard against unusually demanding queries, they are currently set above realistic usage levels and have not been triggered in production. As such, they are not expected to interfere with standard operations or contribute to throttling alongside the request rate limits.

Adapting to Client Needs

Sonar recognizes that clients interact with the GraphQL API in diverse and evolving ways. A universal rate limit may not serve every use case effectively. To address this, Sonar is evaluating a tiered rate-limiting system that would enable differentiated limits based on user roles, usage patterns, or subscription levels—offering greater flexibility and scalability.

API & UI Rate Limiting Policy

To further enhance system stability, performance, and security, Sonar has implemented a unified Rate limiting policy for both API and UI usage. This ensures consistent and fair access across all interaction channels.

Initial Limit

Effective immediately, each user will be limited to 400 requests per minute (RPM) per user.

The Rate limiting policy applies to the total number of requests made by a user, combining activity from both the Sonar web UI and the API. This means that any requests sent while logged into the UI, along with those made via API tokens linked to the same user, are counted together.

For example, if a user generates 100 requests per minute through the API and another 100 through the UI, their total usage is 200 requests per minute, which counts against the shared 400 RPM limit.

Recommendations for API Integrations

If your application integrates with the Sonar API and makes frequent or high-volume requests, it is strongly recommended to create separate user accounts for different types of access. For example, one account can be used for standard UI interactions by staff members, while another is designated specifically for automated API calls by a service user or machine account. This separation helps distribute traffic across individual rate limits, significantly reducing the risk of hitting throttling thresholds due to combined usage under a single account.

Enforcement Details

When a user exceeds the defined rate limit, the system responds with an {"error": "Request limit of 400/min reached."}. Throttling is enforced on a per-user basis, meaning that all requests made using any tokens associated with the same user are counted collectively toward the limit.

Best Practices to Avoid Throttling

To minimize the risk of throttling and ensure smooth API interactions, it’s important to follow several best practices.

  1. Implementing exponential backoff when retrying failed requests can prevent repeated overload attempts.
  2. Distributing API calls evenly throughout each minute, rather than sending bursts of requests, helps maintain a steady request flow.
  3. Additionally, separating UI logins and API integrations across different user accounts prevents shared usage from unintentionally exceeding rate limits.
If your application requires a higher rate limit for valid reasons, contact Support with details about your use case.

How did we do?

Getting Your Data into Sonar

How To Use GraphiQL to Understand the Sonar API

Contact