Hedra job status progress and estimated_completion_at vs Sume events

Hedra's v3 API gives you a status call that returns progress and estimated_completion_at, so you can show a progress bar. Sume's GET /v1/jobs/:id/status returns a status of queued, processing, completed, failed or canceled, and its docs do not describe a percentage or an ETA field. For history you read GET /v1/jobs/:id/events.

Hedra's facts are from its API Quickstart Guide and its developer-platform blog post Hedra for Developers. Sume's are from Jobs and results. All read on 2026-10-02.

How does Hedra's job lifecycle work?

The quickstart lays out three steps: submit with POST /v3/models/{id} and capture job_id from the 202 response, poll GET /v3/jobs/{job_id}/status, then download from GET /v3/jobs/{job_id} using outputs[].url. Authentication uses an Authorization: Key <key_id>:<secret> header. The status response includes progress and estimated_completion_at for user-facing updates, and the quickstart shows COMPLETED and FAILED among the states.

Hedra's August 4 developer post also mentions live Server-Sent Events progress and dynamic ETAs. The quickstart only demonstrates polling, so check which one you can use before designing around SSE.

How does Sume report progress?

queued means Sume accepted the job and it is waiting; workspace concurrency limits apply when workers move it to processing. The events endpoint lists job.created, job.queued, job.started, generation.submitted, job.completed, job.failed, job.canceled and webhook.delivery. That is a timeline of milestones, not a progress percentage.

For a user-facing wait on an avatar clip, show an indeterminate state while processing and use a webhook or a poll with exponential backoff to react to the terminal status.

Comparison

The key practical difference is whether you can draw a progress bar.

What should I build around the gap?

Estimate the wait yourself from past jobs of the same quality tier, or just show elapsed time. Do not poll faster to fake progress: Sume's guidance is exponential backoff and stopping on a terminal status, and the 429 rate_limited response carries retry-after. If you need to know where a job is stuck, read the events instead of re-submitting, since a repeat paid request bills again.