API Rate Limits

Rate limits define how many API requests are allowed per time window. Understanding them — and designing applications that handle them gracefully — is essential for reliable API integration.

---

Definition

API rate limits are restrictions on the number of requests that can be made to an API within a defined time window. When the limit is exceeded, the API returns an HTTP 429 Too Many Requests response and the request is not processed.

Rate limits serve two purposes: protecting the API infrastructure from overload (preventing any single client from consuming excessive server resources) and preventing abuse. For legitimate API users, rate limits define the throughput ceiling their integration must be designed within.

Cuttly API Rate Limits by Plan

Rate limits in Cuttly are measured per account, per 60 seconds. The limit applies to the Regular API. The free plan includes full API access — no paid subscription is required to start building.

Rate limits apply per account. Upgrading a plan increases the limit immediately — no changes to API code required.

How Rate Limits Are Enforced

When a rate limit is exceeded, the API returns:

• HTTP 429 status code — the request is not processed

The application must handle 429 responses explicitly — unhandled 429s that cause immediate retries will quickly exhaust the rate limit again and produce a cascade of failures.

Designing Applications for Rate Limits

Exponential Backoff

When a 429 is received, do not retry immediately. Use exponential backoff — wait progressively longer delays before each retry:

• 1st retry: wait 1 second
• 2nd retry: wait 2 seconds
• 3rd retry: wait 4 seconds
• Continue doubling, up to a maximum wait threshold

Request Batching and Pacing

For bulk operations, pace requests over time rather than sending them all at once. If creating 100 links and the rate limit is 60 requests per minute, spread the requests across two minutes rather than sending 100 in the first few seconds and receiving 40 consecutive 429 responses.

Response Caching

If your application frequently retrieves analytics for the same links, cache the responses. Analytics data does not change between seconds — even a 60-second cache significantly reduces API call volume without meaningful data freshness loss.

Asynchronous Processing

For high-volume link creation workflows, use a queue: accept creation requests faster than the API rate limit allows, add them to an internal queue, and process the queue at the rate limit pace. This decouples the intake rate from the API throughput constraint.

When to Upgrade

Rate limits are a natural growth indicator: when an application consistently hits the rate limit, it has outgrown the current plan tier. Upgrading to a higher plan increases the rate limit without requiring any code changes — the same API key, same endpoints, same integration code, higher throughput.

Related Terms

• API (REST)
• Integrations: Zapier / Make
• CSV Bulk Import