Code by Zapier 225 requests per 10 seconds and Sume 429s

A Zap using Code by Zapier faces two separate limits: Zapier's 225 requests per 10 seconds on Professional and Team, and Sume's own 429 rate_limited on submit endpoints. They are independent. For Sume's, wait for retry-after when present and resend the same Idempotency-Key, so a retry cannot create a second paid job.

Zapier's numbers are from its Code by Zapier article; Sume's from Generation admission and Errors and credits. Read 2026-10-01.

What does Zapier list?

What does a Sume 429 look like?

Submit rate limits fail with 429 rate_limited, which the error table describes as request volume exceeding an abuse-protection limit. Responses can carry ratelimit-limit, ratelimit-remaining, ratelimit-reset and retry-after. This differs from 429 queue_full, which means the workspace has no queue capacity left; see HeyGen vs Sume 429 handling.

How do I retry safely in a Code step?

The docs say to use an Idempotency-Key for every paid submit that may be retried, and not to retry unsafe submits without one. Reuse the key only for exact retries; a different payload under the same key is a 409 idempotency_conflict.

const key = "zap-" + inputData.row_id;
async function submit(attempt) {
  const res = await fetch("https://api.sume.com/v1/videos", {
    method: "POST",
    headers: {
      // Map your Sume API key into an input field of the Code step.
      Authorization: "Bearer " + inputData.sume_api_key,
      "Content-Type": "application/json",
      "Idempotency-Key": key,
    },
    body: JSON.stringify({ model: "sume/auto", prompt: inputData.prompt }),
  });
  const body = await res.json();
  // Retry only rate_limited; queue_full is a different 429.
  if (res.status === 429 && body.error?.code === "rate_limited" && attempt < 3) {
    const wait = Number(res.headers.get("retry-after")) || 5;
    await new Promise((r) => setTimeout(r, wait * 1000));
    return submit(attempt + 1);
  }
  return body;
}
return await submit(0);

Why keep the retry count small?

Each retry spends request budget on both sides, and a Code step has its own runtime ceiling. Cap attempts, return the job id once you have it, and finish the rest in a later step.