Retrying a sume/auto video submit: same key, same job, same price

If you retry a model: "sume/auto" video submit with the same Idempotency-Key, Sume returns the original job, and the docs add a stronger guarantee: Auto's choice of family is a pure function of the normalized request and the catalog version, so a replay prices and routes identically. You do not risk the retry landing on a different, more expensive family.

That guarantee covers an identical request. It says nothing about a request where you changed the prompt, duration or resolution, or about a request sent after the catalog changes.

What stays fixed and what can move

The Video generation docs spell out the lifecycle: send Idempotency-Key to make retries safe, and a replay returns the original job. The routing statement sits under the sume/auto section. Put together:

The family is still not disclosed

A replay returns model: "sume/auto" in the poll response, exactly like the first call. The docs say Sume does not disclose which family served the request and that you should not build on any observable trait of the output to infer it. Determinism of routing is not the same as disclosure of the result.

Errors follow the same opacity. Validation code reports the model you sent, so a rejected request still says sume/auto rather than naming the family that tripped the limit.

Reading the job back

Besides the polling URL, the Video generation docs note that the same job is visible at GET /v1/jobs/{id}/status and GET /v1/jobs/{id}/result. If your retry layer lost the response to the first submit, you can still recover by resending the identical request with the identical key, which returns the original job and its id, rather than hunting for an orphan.

Retries are different from rate limiting. A 429 can mean you ran out of the write budget, that a generation queue is full, or that the rate-limit store is degraded; the API reference says details.scope names which one. Back off on a 429 and keep the key unchanged, since the original submit may or may not have been accepted.

A retry loop that respects this

Generate one key per intent, for example one per SKU and campaign, and store it next to your own record before the first send. On a timeout or a 5xx, resend the identical body with the identical key. On a 409 conflict, stop: you changed the body, so decide whether you want the original job or a new one with a fresh key.

``bash curl -X POST https://api.sume.com/v1/videos \ -H "Authorization: Bearer $SUME_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: sku-4471-hook-a" \ -d '{ "model": "sume/auto", "prompt": "A vertical UGC-style product clip on a desk, natural light", "aspect_ratio": "9:16", "duration": 5 }' ``

Run that twice and the second call returns the first job. Change duration to 6 under the same key and you get the conflict, not a second job.