Skip to main content

Rate Limits

Rate Limits define the maximum number of requests the Nodit API can process per second, per plan. This limit is referred to as Throughput, measured in Compute Units per Second (CU/s). Exceeding the request limit returns a 429 Too Many Requests response.


Throughput by Plan

The table below lists the maximum Throughput for each subscription plan. A higher CU/s allowance means more API requests can be processed concurrently.

SpecStarterStarter PlusDeveloperBusinessEnterprise
Throughput (CU/s)3004006003,000Custom
info

The number of CUs consumed per API call varies by API type. For per-API CU costs, refer to the Compute Unit (CU) documentation.


Handling 429 Responses

When the rate limit is exceeded, the server returns 429 Too Many Requests along with a Retry-After header. The Retry-After value indicates the number of seconds to wait before retrying.

429 Response Example
{
"code": "TOO_MANY_REQUESTS",
"message": "Request rate limit exceeded. Please slow down your requests."
}

Exponential Backoff

Retrying immediately after receiving a 429 response can trigger consecutive errors. Apply an exponential backoff pattern that progressively increases the wait time based on the Retry-After header value.

async function requestWithBackoff(url, options, maxRetries = 5) {
for (let attempt = 0; attempt < maxRetries; attempt++) {
const response = await fetch(url, options);

if (response.status !== 429) {
return response;
}

const retryAfter = response.headers.get('Retry-After');
const waitMs = retryAfter
? parseInt(retryAfter, 10) * 1000
: Math.min(1000 * 2 ** attempt, 30000); // max 30 seconds

await new Promise((resolve) => setTimeout(resolve, waitMs));
}

throw new Error('Max retries exceeded');
}

Optimization Tips

Optimizing request patterns to stay within rate limits enables more efficient API usage under the same plan.

Use Batch Requests
Instead of querying multiple addresses or items individually, use APIs that support array parameters to handle them in a single request. Reducing the number of requests also lowers overall CU consumption.

Eliminate Unnecessary Polling
Rather than sending repeated requests at fixed intervals, use Webhooks or WebSockets to receive data only when events occur. This approach significantly reduces request volume while improving real-time responsiveness.

Minimize Query Scope
When specifying block or time ranges, query only the required interval. Broad range queries consume more CUs and increase the risk of timeout (408) errors.

Apply Response Caching
When the same data is retrieved repeatedly, implement application-level caching to prevent duplicate API calls. Caching is especially effective for data that changes infrequently, such as contract metadata.