Rate Limits

​

How the limit is counted

• Per connection. Every connection has its own budget. A thousand connections can each make 100 requests a minute at the same time.
• Across all three APIs. Proxy, Unified API and MCP requests on the same connection share one budget.
• Per request, not per attempt. Automatic retries happen inside one request and don’t use extra budget. (They do count toward usage.)
• Every MCP message counts. initialize, tools/list and each tools/call are separate requests.

​

When you go over

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

{"status": 429, "code": "rate_limit", "message": "Too many requests"}

​

BundleUp’s limit vs the provider’s

​

Staying under the limit

• Spread out bulk work. For a sync over many records, queue the work and process it at a steady rate per connection (for example, one request every 700 ms) instead of all at once.
• Use bigger pages. Fetch 100 items per request instead of 10.
• Cache stable data. User profiles, channel lists and project lists rarely change between requests.
• Don’t poll faster than you need to. Prefer the provider’s webhooks where it offers them.

​

Handling 429 in code

async function withBackoff(call: () => Promise<Response>) {
  for (let attempt = 0; attempt < 5; attempt++) {
    const response = await call();
    if (response.status !== 429) return response;

    const retryAfter = Number(response.headers.get('Retry-After') ?? 1);
    await new Promise((r) => setTimeout(r, retryAfter * 1000));
  }
  throw new Error('Still rate limited after 5 attempts');
}

const response = await withBackoff(() =>
  client.proxy('conn_abc123').get('/user/repos'),
);