Zapier Heal mode on a failed Sume step: keep the idempotency key

What happens when Zapier's Agentic Management heals a Zap that calls Sume? It depends on whether the step has a stable idempotency key. Zapier's help article describes three modes: Heal, which fixes the workflow when a run fails, Optimize, and a setting to apply fixes automatically (read 2026-10-04). The agent acts on a run that reports a problem. For a paid API that is the interesting case, because a fix that re-sends the request must not buy the same video twice.

Sume's answer is the Idempotency-Key header. A retry with the same key returns the original job. A retry with the same key and a different payload returns 409 idempotency_conflict. Knowing which of those you will hit tells you how to set up the step.

What Zapier says the agent will and won't do

The article says approval is always required for adding tools, actions or branches, for low-confidence changes, and for authentication changes. Agentic Management is in early access on Professional, Team and Enterprise plans (read 2026-10-04). So a fix that rewires an authentication step waits for you, while a smaller fix, if you enabled automatic application, can happen without a prompt.

That is why a Sume step should be safe to re-run on its own. You cannot count on being in the loop for every retry.

A 202 is not a failure

The agent only acts on a run that reports a problem. A Sume job request that is accepted returns 202, which means accepted, not finished, and the step succeeds. If the render later fails, Zapier's run already looked fine, so Heal never sees it. Detect the late failure yourself: poll GET /v1/jobs/:id/status until a terminal state (completed, failed or canceled), or set webhook mode and handle job.failed.

Where a Sume step genuinely errors, you will usually see the standard envelope {error:{code,message,request_id}}: a 429 with retry-after when you exceed your plan's write limit, or 429 queue_full. Those are the failures Heal can reasonably retry, and with a stable key a retry is harmless.

Derive the key from the input

The key should come from the thing being made, not from the run. A key built from the run id changes every time Heal re-runs the step, which defeats the point. Build it from your record id and a hash of the fields that define the output. The snippet below, for a Code step or a local test, produces a stable key and prints it.

If the agent's fix changes the payload, for example it edits the prompt to fix a validation error, the old key now meets a new body and Sume returns 409. That is the correct signal, not a bug: the changed request is a different job. Include the changed fields in the hash so the key moves with them, and the corrected request goes through as a new job.

import { createHash } from 'node:crypto';

function idemKey(recordId, fields) {
  const canon = JSON.stringify(fields, Object.keys(fields).sort());
  const h = createHash('sha256').update(canon).digest('hex').slice(0, 24);
  return 'zap-' + recordId + '-' + h;
}

console.log(idemKey('rec_42', { prompt: 'A paper boat', model: 'sume/auto' }));

Setup checklist

Before turning on automatic fixes for a Zap that spends credits, check the following. For the broader pattern of handling a Sume 202 in Zapier, see API by Zapier and the accepted-not-finished response, and for the same idea in a workflow runner, re-running a GitHub workflow safely.

• Every paid Sume step sends an Idempotency-Key derived from the input.
• The step uses one auth header, since both together return 401.
• A separate step or Zap checks job status and handles failed and canceled.
• Authentication changes stay on the approval-required path.
• Keep automatic fixes off until a few Heal suggestions have been reviewed by hand.