Prevent duplicate physical prints when retrying CloudPrint print-job requests after a timeout or network failure.
## Why printing needs idempotency A timeout can happen after CloudPrint accepted the request but before your backend received the response. Creating a new job at that point can print the same label or document twice. ## Key design Build a stable key from the business operation, such as `shipment-18451-label-v1`. Keep it opaque, at most 128 characters and identical for retries of the same payload. An intentional reprint is a new operation and needs a new key. ## Reuse rules The same account, key and payload return the original result. Reusing the key with a different payload returns `409 Conflict`. Persist the key before the first request so a worker restart does not generate a replacement. ## Recovery after uncertainty After a network failure, retry the same create request with the same key. Once a `print_job_id` is known, persist it and read job status instead of creating another job. ## Related documentation