Temporal Maximum Attempts 1 and a paid Sume submit
Standalone Activities default to at-least-once retries. Maximum Attempts 1 gives at-most-once, but a Sume Idempotency-Key lets you keep retries safely.

Use the Sume Idempotency-Key header and keep Temporal's default retries. Setting Maximum Attempts to 1 makes a Standalone Activity at-most-once, which also means one dropped connection loses a submit you could have retried for free.
Temporal facts are from its Standalone Activity docs and the Server v1.32.0 release page; Sume facts are from Communication modes and Errors and credits. All read 2026-10-01.
What did Temporal change?
The v1.32.0 release notes say Standalone Activities are enabled by default on the server, with delayed starts, operator APIs and batch operations. The docs describe them as top-level Activity Executions started by a Client with no Workflow, so there is no Event History and no deterministic replay. The docs say they are generally available in Temporal Cloud and need CLI v1.9.1+ and Server v1.32.0+.
What does a retry do to a paid submit?
Per the docs, the default retry policy retries with exponential backoff until the activity succeeds or Schedule-To-Close expires, so execution is at-least-once. Setting Maximum Attempts to 1 gives at-most-once. The docs also state that activity code must be idempotent.
A Sume submit is paid, so it is the call that most needs that property. If the first attempt reached Sume but the response never reached your worker, a plain retry would be a second job.
| Setting | Temporal behavior (docs) | Effect on the Sume submit |
|---|---|---|
| Default retries | At-least-once until success or Schedule-To-Close | Safe only with an Idempotency-Key |
| Maximum Attempts 1 | At-most-once | A lost response is a lost submit |
| Same key, same payload | Not applicable | Sume returns the original job instead of billing twice |
| Same key, different payload | Not applicable | 409 idempotency_conflict |
How do you make the submit activity idempotent?
Derive the key from your own business id, not from a random value generated inside the activity, so every attempt sends the same key. Reuse a key only for the same operation and payload; a different payload under the same key returns 409 idempotency_conflict.
Throw on any error so Temporal retries, and keep the call to a submit with mode: "async". The result comes from a separate poll or a webhook, not from this activity.
import { createSumeClient, generateVideoV1 } from "@sume-com/sdk";
const client = createSumeClient({ apiKey: process.env.SUME_API_KEY! });
// `key` must be the same on every attempt of the same logical submit.
export async function submitVideo(prompt: string, key: string) {
const { data, error } = await generateVideoV1({
client,
headers: { "idempotency-key": key },
body: { prompt, mode: "async" },
});
if (error) throw new Error(JSON.stringify(error));
return data!.data.request_id;
}Where does polling belong?
Poll GET /v1/jobs/{id}/status and honor next_poll_after_seconds. A client-side timeout does not cancel the job and it still bills, so store the job id before you wait. See how to cancel from Temporal when you need to stop one.
Sources
Related posts
More in Developers
- Threads API: wait about 30 seconds before publishing a container
Threads suggests waiting on average 30 seconds after creating a media container before threads_publish. Poll the container status, like a Sume job poll.
- TikTok brand_organic_toggle vs brand_content_toggle on AI video
Set brand_organic_toggle for your own business, brand_content_toggle for a paid partnership, and is_aigc for AI video. How to carry the flags with each clip.
- TikTok rate_limit_exceeded: 6 requests a minute per access_token
TikTok Direct Post allows 6 requests a minute per user access_token and returns 429 rate_limit_exceeded past it. Space publishes; Sume limits only generation.
- TikTok spam_risk_too_many_posts vs reached_active_user_cap
Two daily TikTok 403s: spam_risk_too_many_posts is the per-user API post cap, reached_active_user_cap is your client quota. Hold videos till tomorrow.
Written by Sume