Zapier accepted my Sume webhook but the Zap ran minutes later

A 200 from Zapier means Zapier took the request, not that your Zap has run, and Sume treats any 2xx as delivered and does not resend. Zapier's rate-limit page says that during high activity it may return 200 and delay webhook processing by several minutes, so poll the run or job as a backup.

Sume behavior is from the Run webhooks docs; the Zapier text was read 2026-09-30.

Why does Sume not retry a delayed Zap?

Retries happen on failed deliveries, up to 10 attempts. A 2xx ends the sequence. Redirects are not followed and count as a failed attempt, so a URL that answers with a redirect is retried rather than treated as delivered.

How do I back it up with a poll?

Keep the run id, then check the receipt on a schedule. In JavaScript, the SDK's waitForRun (10-minute default) and subscribeFormatRun (20-minute default) do the polling. From any scheduler, a GET of the run receipt does the same job.

curl https://api.sume.com/v1/format-runs/arun_demo \
  -H "Authorization: Bearer $SUME_API_KEY"

What should the Zap do with a duplicate?

Dedupe on request_id, which equals the run_id and is stable across retries. Job webhooks use job_id instead. If the webhook and the poll both arrive, the second one is a no-op.

What if the payload is null?

Run webhooks send payload: null when the body would pass 1 MiB. Fetch the full result from result_url instead of expecting it in the Zap trigger.