Higgsfield cancel queued request: 202 or 400, and the Sume match
Higgsfield cancels only queued requests (202, else 400). Sume cancels a job before generation starts, or returns 409 job_generation_already_started.

Higgsfield lets you cancel a request only while it is still queued: POST /requests/{request_id}/cancel returns 202 when the request was canceled and 400 once processing has started. Sume works the same way in spirit. POST /v1/jobs/{id}/cancel succeeds only before generation work starts, and after that it returns 409 job_generation_already_started with details.cancelable: false.
The two cancel contracts side by side
The two APIs agree on the rule and differ on the status codes and the lookup rules. Higgsfield's cancel page also says a request that does not exist or belongs to another account returns 404. Sume scopes jobs to a workspace and to the member whose key created them, and only that member can cancel.
| Case | Higgsfield | Sume |
|---|---|---|
| Still waiting to start | 202, request canceled, no body | Job moves to canceled |
| Already running | 400, already started | 409 job_generation_already_started, details.cancelable: false |
| Already canceled | Not described on the cancel page | Idempotent: returns the same canceled job |
| Unknown or foreign id | 404 | 404 not_found |
| Bad credentials | 401 | 401 unauthorized |
Which state can you still cancel
Higgsfield's lifecycle page calls queued cancellable and in_progress non-cancellable. On Sume the equivalent states are queued (accepted, waiting for a concurrency slot) and processing. For paid generation, queued is a normal accepted state, so a job that is waiting behind your workspace concurrency limit is exactly the kind you can still cancel.
What happens to the money
Higgsfield says a successfully canceled queued request is refunded. Sume's core workflow reserves the cost on submit, captures actual cost on success, and refunds on failure or cancellation before capture. Either way, a cancel that wins the race costs nothing, and a cancel that loses it does not stop the bill.
What to do with the refusal
Treat a 400 from Higgsfield or a 409 from Sume as information, not a failure: the work is running and will finish. Read the job result instead of resubmitting, because a second submit pays for a second clip.
Also remember that a client-side timeout cancels nothing on Sume. The jobs guide says the job keeps running and still bills until you stop it with an explicit cancel.
- Store the job id from the submit response before you do anything else.
- Cancel early: the window closes when generation starts.
- On
409, pollGET /v1/jobs/{id}/statusuntil a terminal state. - Never resubmit just because a cancel was refused.
curl -X POST https://api.sume.com/v1/jobs/job_123/cancel \
-H "Authorization: Bearer $SUME_API_KEY"Sources
Related posts
More in Developers
- Higgsfield concurrency limit returns 400, not 429: Sume's answer
Higgsfield answers 400 at your concurrency cap and sends no Retry-After. Sume queues valid jobs and returns 429 queue_full only when the queue is full.
- Genjutsu missing from /v1/video-router/models: when it is listed
If higgsfield-genjutsu is not in GET /v1/video-router/models, Sume hides it when its provider is not configured. How to check, and what to use instead.
- Higgsfield hf_webhook query parameter vs Sume callback_url
Higgsfield takes the webhook as an hf_webhook query parameter; Sume takes callback_url in the body and signs the delivery. Payload shapes and a Python verifier.
- Higgsfield Idempotency-Key: 422 on a changed body, vs Sume 409
Both APIs replay the original job for a repeated Idempotency-Key. A changed body gets 422 on Higgsfield and 409 idempotency_conflict on Sume. Rules compared.
Written by Sume