Idempotency Keys Now Cover Create, Run, and Replay

If you've ever built an integration against any API, you know the retry problem: a request times out, you don't know whether it actually succeeded, so you retry — and if the original request actually did go through, you've now done the thing twice. For a workflow that sends an email, charges a payment, or writes to a CRM, "twice" isn't a cosmetic issue. Workflows now supports Idempotency-Key headers on exactly the routes where that risk is real.

The four routes covered

Idempotency-Key support now applies to workflow.create, workflow.create_from_template, workflow.run, and workflow.replay — the four actions that actually create a side effect rather than just reading state. Send the same idempotency key with a retried request to any of these, and the platform recognizes it as the same operation rather than executing it again. This pairs with audit logging already in place across create, update, delete, run, replay, credential, environment, and secret-rotation actions, so both the safety mechanism and the record of what happened are covered together.

Why this matters specifically for workflows

A workflow that sends a Slack message, updates inventory, or calls a payment API is exactly the kind of thing you don't want firing twice because a network blip made your client retry a request it wasn't sure had landed. Idempotency keys are one of the most consistently cited "must-have" practices for anyone wiring real business logic into an automation platform — not a nice-to-have, but the baseline expectation before you trust production data to it.

What this means for you

If you're calling these four routes programmatically — through your own integration, a CI pipeline, or any retry-capable client — start sending an Idempotency-Key header with each request. It costs you nothing when everything goes smoothly the first time, and it's the difference between a safe retry and a duplicated side effect when it doesn't.