Sume 503: provider_capacity_exceeded vs provider_not_configured

A 503 from the Sume API does not have one meaning. provider_capacity_exceeded means Sume's provider dispatch queue is full, so retry later with the same idempotency key. provider_not_configured means provider execution is unavailable in this runtime, so do not retry aggressively and check catalog and runtime status. job_ledger_not_configured means job persistence is unavailable, so treat it as service unavailable.

The status code is the same, the right client behavior is not. This post lays out the three and how they differ from the 429 errors you may already handle.

What does each 503 code mean?

The Errors and rate limits page groups these under provider and worker backpressure. They are returned before provider work is accepted, which matters for billing: a request rejected at this stage did not start a generation.

How is a 503 different from 429 queue_full?

queue_full is a 429 and it is about your workspace: accepted generation capacity is used up, and it clears when one of your own queued or processing jobs finishes or is canceled. A 503 provider_capacity_exceeded is about Sume's dispatch side, so cancelling your own jobs is not the lever.

Rate limiting is a third thing again. rate_limited is a 429 for request volume, and the docs say to back off and use retry-after when present. If you want a deeper comparison of the 429 and 503 families, 429 vs 503: rate limit or overload covers the general idea.

Why must the retry reuse the same Idempotency-Key?

The docs say not to retry unsafe submit requests without an Idempotency-Key. A 503 can leave you unsure whether a job was created, and a retry without a key risks a second paid job. With the same key on a retry of the same operation and payload, the request returns the original job instead of billing again.

The same key must not be reused for a different operation or payload: that returns 409 idempotency_conflict. Reuse keys only for exact retries.

curl -X POST https://api.sume.com/v1/image-1.0/generate \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: hero-shot-2026-10-02-001" \
  -d '{"prompt":"Product hero shot of a matte black bottle on marble","mode":"async"}'

Will a failed 503 submit cost me anything?

These errors are returned before provider work is accepted, and the docs describe the reservation being released or refunded for failed admission where applicable. Check GET /v1/balance after a burst of 503s if the numbers look off, and rely on the idempotency key to prevent a duplicate job when you retry.

What retry schedule is reasonable?

The docs do not publish a number of retries or a delay for 503 errors, so any schedule is your choice and should stay conservative. A sensible shape, consistent with the guidance above: for provider_capacity_exceeded, back off with growing delays and jitter and cap the number of attempts; for provider_not_configured, stop after a small number of attempts and look at the catalog rather than looping; for job_ledger_not_configured, treat it like an outage and alert instead of hammering.

Keep a polling fallback for anything already submitted. A 503 on a new submit says nothing about jobs that are already running, and those keep their own status through status_url.

If a 503 persists, send the request id from the error body to Sume support. It is safe to share. Leave out API keys, signed URLs and raw media URLs.