Temporal Activity ID policies are not a Sume Idempotency-Key

No. Temporal's Activity ID uniqueness rules decide whether Temporal accepts a second activity with the same ID. They are enforced inside Temporal, so Sume never sees them, and a paid submit that you start twice can still be billed twice unless the HTTP call carries an Idempotency-Key.

Temporal facts are from its Standalone Activity docs, Sume facts from Communication modes and Errors and credits, all read 2026-10-01.

What do the Activity ID policies cover?

The docs list two settings for Activity ID uniqueness. A Conflict Policy chooses between Fail and Use Existing, and a Reuse Policy chooses between Allow Duplicate, Allow Duplicate Failed Only and Reject Duplicate. Both are about Activity Executions in Temporal, and Standalone Activities arrived enabled by default in Server v1.32.0.

What does Sume dedupe on?

Sume dedupes on the Idempotency-Key header of the submit. An exact retry returns the original job, and the same key with a different operation or payload returns 409 idempotency_conflict.

Can one value serve as both?

Yes, and it is the simplest design: use your business id, such as an order number plus a version, as the Activity ID and as the header value. Then a Temporal duplicate is refused by Temporal, and a retry that slips past it is absorbed by Sume.

Remember the rule on payloads. If a Reuse Policy lets you run the same Activity ID again with a changed prompt, bump the version in the key too, or Sume answers 409 idempotency_conflict.

What should the activity itself do?

Keep it to submit and return the job id. The submit helper from the Maximum Attempts post takes the key as an argument, so the Activity ID can be passed straight in. Poll status or take the webhook elsewhere, and keep polling as a backup.