Remove backgrounds from 2,000 marketplace images for $45 with RMBG

Sume RMBG 1.0 charges $0.0225 per image, and the catalog states the price does not vary by image size. For 2,000 product photos that is 2,000 x $0.0225 = $45.00.

Batch cost table

Rate from the public catalog, read 2026-10-09.

Request

The endpoint is POST /v1/rmbg-1.0/remove (or POST /v1/models/sume/rmbg/v1.0/runs). The body is strict: image_url (a public HTTPS URL), optional sync_mode, metadata, and the usual communication fields. Sending model, endpoint or provider_endpoint is rejected, because RMBG 1.0 picks its provider model on the server. Poll GET /v1/jobs/:id/status, then read /result.

curl -X POST https://api.sume.com/v1/rmbg-1.0/remove \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: rmbg-shoe-001" \
  -d '{"image_url":"https://example.com/shoe-001.jpg"}'

Running a batch

• Use one idempotency key per image (for example the SKU) so a retry never charges twice.
• Keep your balance above the total; each job reserves its price at submit.
• On hosted MCP the tool is rmbg_create, a paid write that needs idempotency_key.
• Check the Sume job result for the cutout URL; the docs do not promise a specific pixel size, so verify one sample before the full run.

What it is not

RMBG removes backgrounds. It does not upscale or relight. If a cutout needs more pixels afterwards, the Image Upscale job is a separate $0.20 per image, which would add $400 to a 2,000-image batch (2,000 x $0.20).

Budget planning

The cost is linear and independent of size, so you can budget from the SKU count. A catalog with 3 photos per SKU and 700 SKUs is 2,100 images, which is 2,100 x $0.0225 = $47.25. If you only cut out the hero shot, 700 x $0.0225 = $15.75. Run 20 images first (20 x $0.0225 = $0.45) to confirm the edge quality on your own photos before committing the full set. Every media job follows the same lifecycle: submit with an Idempotency-Key, receive a job, poll GET /v1/jobs/:id/status until it is ready, then read GET /v1/jobs/:id/result. A retry with the same key does not queue a second job, so a network error during submit never doubles a charge.