Avoiding Duplicate Tasks When a Retry Fires Twice
Task creation in Tasks is now idempotency-key aware, so a retried create request can't accidentally leave behind a duplicate task.
If you're integrating against the Tasks API — a webhook relay, a retry-happy client, anything that might call create more than once for the same intended task — there's now a direct way to make that safe.
What's new
Task creation supports an idempotency key. Attach one to a create request, and if that same request gets retried — a network blip, a timeout that makes a client resend, whatever the cause — it won't produce a second task. The same key tells the platform this is the same logical creation, not a new one.
Why this matters more than it sounds like
Idempotency is the one piece of "grown-up" engineering practice that shows up repeatedly in any serious discussion of building reliable automated systems — and it applies just as directly to a plain task-creation API as it does to an AI agent taking an action on your behalf. A retry is not an edge case; it's a near-certainty for any integration running long enough, and without an idempotency key, that retry becomes a duplicate row someone has to notice and clean up later.
Where to use it
If you're building an integration that creates tasks programmatically — from a form, a webhook, another system's event — generate a stable key per logical creation and send it along. It's a small addition on your side that removes an entire category of duplicate-cleanup work later.