Rate limits

What is enforced today

Velora is designed to rate-limit per action, per client— each budget tied to a specific write-heavy endpoint, or to the OAuth scope behind it, counted against your application's access token over a rolling one-minute window. Read endpoints are not individually throttled today.

Handling a rate limit

When you exceed a limit you get a 429 Too Many Requests. Where a Retry-After header is present it tells you how many seconds to wait — honor it. Do not depend on it being there: back off exponentially either way, so your client behaves whether or not the header arrives.

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

{
  "statusCode": 429,
  "message": "ThrottlerException: Too Many Requests"
}

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

    if (response.status === 429) {
      const retryAfter = parseInt(
        response.headers.get('Retry-After') || '60',
        10
      );
      console.log(`Rate limited. Retrying after ${retryAfter}s...`);
      await sleep(retryAfter * 1000);
      continue;
    }

    return response;
  }

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

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

Best practices

Budgets by category — not yet enforced

Write and action endpoints are budgeted per category, tied to their OAuth scope. All windows are one minute unless stated. These are the budgets we design against and intend to enforce per app — treat them as the ceiling to build toward, not as a limit that will stop you. We would rather tell you that than let you design a retry strategy around a number we do not apply.

A scope or endpoint not listed here has no dedicated per-minute cap today. We add caps as endpoints ship; this page is the source of truth and is dated at the top.

Endpoint reference

Sandbox, Production & Partner