Keep a durable request identity
Every REST generation uses an Idempotency-Key header; MCP generation uses idempotencyKey. The key is scoped to the account and operation. Store the exact body alongside it before sending the request. Keys are 1–255 characters after trimming.
Same key, same request
An identical repeat returns the accepted task with replayed: true. Concurrent repeats serialize at acceptance so only one generation reservation and charge can win. A key reused with different parameters returns IDEMPOTENCY_CONFLICT; it does not silently change the original task.
Timeout or unknown outcome
A connection loss can happen after acceptance. Resend the same body and key, then query the returned task. Do not switch keys, change destination or alter parameters while trying to recover that request. A provider response that cannot be reconciled is handled by the original media workflow rather than blindly resubmitted.
Intentional retries after terminal failure
Review the error and refund state first. For a confirmed terminal failure, a corrected new generation uses a new key. For a partially completed batch, keep successful items and request only the failed subset when the business permits. This is a new chargeable request, not a replay.