API rate limits

Elido rate-limits the API per key, not per workspace. That means each integration you build can saturate its own limit without starving the others. This article covers the limits per plan, the headers to read, and how to back off cleanly.

The numbers#

Sustained limits per key:

Plan	Per minute	Burst
Free	60	120
Pro	600	1200
Business	6000	12000

Burst is what you can briefly exceed in a 10-second window. Sustained is the steady-state cap the bucket refills at.

There are no per-endpoint limits — a GET /v1/links counts the same as a POST /v1/links. The only exceptions are:

• POST /v1/bulk-import — 5 active imports per workspace at once.
• POST /v1/links with a custom slug colliding with an existing slug — these still count but don't refund the slot on conflict.
• GET /v1/analytics/timeseries with interval=second — capped at 60/minute even on Business, because the underlying ClickHouse query is heavier.

Response headers#

Every API response includes:

X-RateLimit-Limit: 600
X-RateLimit-Remaining: 587
X-RateLimit-Reset: 1747386240

X-RateLimit-Reset is a Unix timestamp telling you when the bucket refills to full. Use it to schedule retries rather than fixed delays.

What 429 looks like#

When you exceed the limit:

HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/json

{
  "error": "rate_limited",
  "message": "API rate limit exceeded for this key",
  "retry_after_seconds": 12
}

Retry-After is in seconds. Wait that long, then retry. The SDKs do this automatically with jitter; if you're writing a raw HTTP client, do the same.

Backoff strategy#

If you're hammering the API (a one-off bulk job, a backfill), pace your client at the steady-state limit rather than the burst. A naive loop hits the burst cap, then stalls for 50 seconds, then hits the burst again — averaging worse than just pacing.

Pseudocode:

const limit = 600; // per minute
const delayMs = (60 * 1000) / limit; // 100ms between requests

for (const item of items) {
  await fetch(...);
  await sleep(delayMs);
}

This pattern uses 100% of the limit with zero 429s.

Concurrency#

Concurrent requests share the bucket. If you fire 100 parallel requests from a worker pool on the Pro plan (600/min), the first 100 succeed instantly; the bucket then refills at 10/sec. Your worker pool should target a sustained rate, not a queue depth.

Per-key vs per-IP#

The bucket is per key, not per IP. If you're using the same key from 10 machines, the 10 machines share the limit. Issue a key per machine if you need 10× headroom.

The IP layer has a separate, very generous limit (10,000/min/IP) intended only to stop runaway clients. You'll never hit it in normal use; if you do, the response is 429 with the body "error": "ip_rate_limited".

Idempotency keys don't bypass#

Sending the same Idempotency-Key repeatedly still counts each request against your bucket — we can return the cached response without doing the underlying work, but the count is incremented. Don't loop on idempotency keys as a retry strategy.

Raising limits#

If your use case genuinely needs more than 6000/min sustained, email support@elido.app with:

• Your workspace ID.
• The integration name.
• Expected steady-state and peak request rate.
• What endpoints (so we can plan capacity for the heavy ones).

We grant per-key limit bumps to enterprise customers under contract, usually within one business day.

Troubleshooting#

Suddenly getting 429s on a key that used to work. Either your code started looping (most common), or someone else on the workspace started using the same key. Check the API key's Usage tab in the dashboard for a per-minute graph.

429s on the first request of the day. Free-tier buckets reset on a rolling window, not midnight UTC. If you tested the limit yesterday at 23:59 and it hasn't fully refilled at 00:01, the first burst is still rate-limited. Wait 60 seconds.

X-RateLimit-Remaining is negative. Burst overshoot. The number tells you how deep into the negative you are; multiply by 60/limit to get the seconds until you're back to zero.