Clipdrop remove-background API: 60 requests a minute vs Sume RMBG

Clipdrop's remove-background API answers a multipart upload, caps it at 25 megapixels and 30 MB, charges one credit per successful call, and limits each key to 60 requests per minute. Sume's RMBG 1.0 does the same job differently: you send a public HTTPS image_url, get a job back, and read a PNG with alpha from the result.

Clipdrop's numbers come from its Remove background API page and Sume's from the Sume OpenAPI schema, both read on 2026-10-03.

What does the Clipdrop API accept and return?

The endpoint is https://clipdrop-api.co/remove-background/v1, a POST with a multipart/form-data body holding a required image_file and an optional transparency_handling. Auth is an x-api-key header. Input can be PNG, JPG or WEBP up to 25 megapixels and 30 MB.

The response is image data matching the accept header, defaulting to PNG, with image/png, image/webp and image/jpg listed. One successful call is one credit.

How does Sume RMBG take an image?

The route is POST /v1/rmbg-1.0/remove and the only required field is image_url, a public HTTPS URL. There is no multipart upload. The schema also takes sync_mode, metadata, and the usual mode and webhook_url options. Completed results expose mirrored PNG artifacts with alpha.

Sume's schema lists no input megapixel or file-size field, so check your images against the job result and not against a number I cannot quote.

curl -X POST https://api.sume.com/v1/rmbg-1.0/remove \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "image_url": "https://example.com/inputs/portrait.png",
    "mode": "async"
  }'

How do rate limits and waiting differ?

Clipdrop is synchronous: the call returns the image, and 60 requests per minute is your throughput ceiling per key. For a catalog you throttle your own loop to one request a second.

Sume returns a job id in every mode. async gives you a status_url and result_url; sync and subscribe block for at most wait_timeout_seconds, with a maximum of 30, and if the job is still queued the response says so and you poll instead of resubmitting. result returns 409 job_not_completed until result_ready is true. Webhooks deliver terminal events only. The jobs and results page has the full flow, and the MCP tool is rmbg_create.

What about transparency and re-cuts?

Clipdrop's call has an optional transparency_handling field, and its page does not describe its values in the part I read, so check it before sending images that already have alpha. Sume handles one case itself: when an input has substantial fully-transparent pixels, it flattens onto mid-gray #808080 before the provider sees it, and it is still one billed removal.

For either service, test a re-cut of an existing PNG cutout, because that is where edge halos tend to appear. Cutout then upscale covers the order of operations if you also need more pixels.

Which should you use for a product catalog?

If you already live in Clipdrop credits and your images fit under 25 MP, its call is simple, and the 60 per minute limit sets a clear pace. If the images are Sume artifacts or public URLs and you want job ids, webhooks and one wallet with the rest of your media jobs, use RMBG.

Neither route decides how the cutout will look on your page. Run a handful of your hardest products first, such as glass, hair and white-on-white, and compare.