# Vercel's Workflow SDK adds atomic idempotent starts

published: 2026-11-04T20:05:39.764Z
topic: infrastructure
source: https://vercel.com/changelog/atomic-start-hooks-in-the-workflow-sdk
url: https://aiagentnews.io/stories/vercel-s-workflow-sdk-adds-atomic-idempotent-starts

Vercel's Workflow SDK can now admit a run and claim a hook in one atomic step, so duplicate starts fail safely. The change replaces the older getHookByToken() then start() pattern, which left a duplicate-start race between the lookup and the start.

Vercel says the start() function in the Workflow SDK can now admit a run and claim a hook in a single atomic step, closing a gap in the older pattern of calling getHookByToken() and then start(). A duplicate start with the same token throws HookConflictError, which carries the conflictingRunId of the run that owns the token, and no second run is created.

The token works as an idempotency key taken from the developer's own domain, such as an order, invoice, import or request ID. The claimed hook exists from the moment the run is admitted, so resumeHook can deliver a payload before the run begins executing, and early payloads are buffered and delivered in order.

Inside the workflow, createHook with the same token binds to the already-claimed hook and registers nothing new. Setting experimental_minRetention keeps the token unavailable after the run ends, counted from the start() call, so late duplicates are still refused. The changelog says developers should upgrade to workflow 5.3.1 to use the feature.

## Why it matters if you build agents

Agents that handle retried webhooks or repeated requests can drop the separate lookup and catch HookConflictError to route duplicate payloads to the run that already owns the token.

Use experimental_minRetention if late duplicates should still be refused after a run has finished.

Review the idempotency documentation and the workflow 5.3.1 upgrade before relying on the new start behavior, since the feature is marked experimental.