Replicate data URIs under 1 MB vs Sume's public HTTPS image URLs

Replicate gives you three ways to send a file to a model: a hosted URL, a local file (its client library uploads files up to 100 MB), or a base64 data URI, which its docs recommend only for files under 1 MB. Sume gives you one: a fetchable public HTTPS URL in the field the endpoint names. There is no data URI or direct upload path in the default Sume public API.

If your app holds images in memory or on disk, porting from Replicate means hosting them somewhere first.

What does Replicate document for file inputs?

The Replicate input-files page lists three approaches. A hosted file is passed as a URL. A local file can be passed as a Blob, File or Buffer and the library handles the upload, supporting files up to 100 MB. A data URI is accepted but, per the page, is best kept to files under 1 MB because of the size cost of base64 encoding.

The page does not state an expiry for uploaded files. A separate Replicate webhooks page says input and output files for API predictions are automatically deleted after an hour, which matters if you plan to reuse an uploaded file across predictions (see our note on Replicate file expiry).

What does Sume accept?

Sume's docs say generation requests accept fetchable public HTTPS media URLs directly in the documented fields. Localhost, private-network, non-HTTPS, signed or private URLs and mismatched content types are rejected before generation is submitted. The Image API takes image_urls, 1 to 10 public HTTPS URLs for edit and reference requests, and the Video API takes images inside frame_images and input_references as image_url objects.

Sume does have asset routes (/v1/assets and /v1/assets/upload-url), but the API reference marks them hidden from the public OpenAPI and says to prefer public HTTPS media URLs. So treat upload as unsupported for normal integrations.

How do I port a data URI call?

The practical change is a hosting step before the call. Put the image on storage you control (any public HTTPS location that returns the right content type), then pass its URL. If you used a data URI because the file is private, you need a short-lived public link, but note Sume rejects signed or private URLs, so a signed bucket link will fail the fetch check. A plain public object with an unguessable name is the pattern that fits the rules, and you should delete it afterward.

Here is an image edit call on Sume:

curl -X POST https://api.sume.com/v1/images \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: edit-hero-0001" \
  -d '{"model":"sume/auto",
       "prompt":"Same product, warm studio light",
       "image_urls":["https://assets.example.com/u/7f3a9c/hero.png"]}'

What errors will I see?

When Sume cannot fetch or mirror an input, the docs list image_not_fetchable and input_media_unreachable among the capacity and runtime errors. The fix is to check that the URL is a public HTTPS image, then retry or contact support with the request_id. Large JSON bodies get 413 payload_too_large, and the Formats docs state a 4 MiB request body cap, which is another reason to send media by URL, never inline.

Replicate's counterpart is simple: stay under the 1 MB data URI guidance or use the upload helper. Sume moves the weight to your storage, and in return it returns results as durable Sume media URLs, not temporary ones.

Which is easier?

For quick scripts with a local file, Replicate is easier today. For a server pipeline where inputs already live in object storage, Sume's URL-only rule costs you nothing. Compare the rest in Sume vs Replicate, and read the exact rules in Sume media inputs.