Rate limits

Limits are counted per key over a sliding one-minute window. Defaults: 600 requests/minute for workspace keys, 1200 for partner keys; your plan may set different values, and the actual limit is always in the response headers.

Headers

Every response carries the current state:

X-RateLimit-Limit: 600
X-RateLimit-Remaining: 273
X-RateLimit-Reset: 1755081600

• X-RateLimit-Limit — the window capacity of this key.
• X-RateLimit-Remaining — requests left in the current window.
• X-RateLimit-Reset — Unix time (seconds) when the window frees up.

Over the limit, the API answers 429 with Retry-After:

{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded, retry later",
    "doc_url": "https://linkprofit.com/docs/api/errors"
  }
}

Retry-After: 12

The window slides

The counter is not reset at the top of the minute: a burst at 10:00:55 still counts against the window at 10:01:05. Plan for a steady rate rather than minute-aligned bursts.

Rejected requests count too — a tight retry loop on 429 only keeps the key locked out.

A retry that behaves

async function withRateLimit(request) {
  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = await request();
    if (response.status !== 429) return response;

    const wait = Number(response.headers.get("retry-after") ?? "1");
    await new Promise((resolve) => setTimeout(resolve, wait * 1000 + attempt * 250));
  }
  throw new Error("Rate limit retries exhausted");
}

Honour Retry-After instead of guessing, add jitter so parallel workers do not retry in lockstep, and cap the attempts.

Staying under the limit

• Watch X-RateLimit-Remaining and slow down before hitting zero.
• Use POST /links/bulk — one request creates up to 100 links.
• Prefer webhooks to polling: events are pushed to you within seconds and cost no requests at all.