remove.bg API rate limit: 500 per minute, weighted by megapixels

remove.bg's API limit is 500 images per minute, and the page says the real number depends on input megapixels: a 4 MP image counts as 500 / 4 = 125 images per minute. Sume's limit is different in kind: a per-key requests-per-minute budget set by plan, where one RMBG request is one image regardless of its size.

Vendor numbers are from the remove.bg API page; Sume numbers are from Authentication, both read 2026-10-01.

How does remove.bg weight the limit by megapixels?

The page gives worked examples. Exceeding the limit returns HTTP 429 and, per the page, no credits are charged. It also lists X-RateLimit-Limit and X-RateLimit-Remaining response headers.

How does the Sume limit work?

Every API key gets a request budget per minute across /v1, set by the workspace plan. Reads and writes have separate budgets, so polling a job cannot 429 your own submits. Submitting a background removal is a write.

The docs table lists these write budgets per minute: Free 120, Pro 300, Startup 600, Scale 1200. Reads get forty times the write number. The request body for RMBG 1.0 is a public HTTPS image_url, so image size does not change how many requests you are allowed.

What should a bulk catalog job do on a 429?

Sume's docs say a 429 means the plan's requests-per-minute budget was exceeded: back off and retry after retry-after. Every response carries ratelimit-limit, ratelimit-remaining, ratelimit-reset, and retry-after is sent on 429. Read ratelimit-remaining instead of counting requests yourself.

A 429 names the budget in error.details.scope (read or write). Request rate is also separate from generation capacity, which the plan's concurrency limit governs. For queueing patterns see batch image generation concurrency limits.

async function removeBackground(imageUrl) {
  for (let attempt = 0; attempt < 5; attempt++) {
    const res = await fetch("https://api.sume.com/v1/rmbg-1.0/remove", {
      method: "POST",
      headers: {
        Authorization: "Bearer " + process.env.SUME_API_KEY,
        "Content-Type": "application/json",
        "Idempotency-Key": "rmbg-" + crypto.randomUUID(),
      },
      body: JSON.stringify({ image_url: imageUrl }),
    });
    if (res.status !== 429) return res.json();
    const wait = Number(res.headers.get("retry-after") ?? 1);
    await new Promise((r) => setTimeout(r, wait * 1000));
  }
  throw new Error("still rate limited");
}

Which limit should I plan around?

With remove.bg, sort the catalog by resolution first, since large files use more of the 500. With Sume, plan around your plan's write budget and the retry-after header. The two numbers are not interchangeable, so measure your own catalog's size mix against each page before picking a batch rate.