Code by Zapier 10-minute runtime vs Sume's 30-second sync wait

Code by Zapier can run 10 minutes on action steps, but Sume's sync wait caps at 30 seconds. Submit async, keep the job id, and poll instead of holding the step.

4 min readSume
All posts

A longer Code by Zapier runtime does not lengthen Sume's wait. Zapier lists extended runtimes up to 10 minutes on action steps, but Sume's sync mode waits at most 30 seconds, and subscribe is only an alias of it. Submit with async, store the job id, and check back by polling status_url.

Runtime numbers are from Zapier's Code by Zapier article (updated July 13, 2026); Sume's from Jobs and results. Read 2026-10-01.

What are the Code by Zapier limits?

Code by Zapier runtimes per Zapier, read 2026-10-01.
PlanStandard runtime
Free1 second
Professional30 seconds
Team30 seconds
Enterprise2 minutes
Extended (Pro, Team, Enterprise)Up to 10 minutes, action steps only

Does a 10-minute step make sync last longer?

No. The Sume docs say the mode decides how you learn the outcome and never changes how long the job takes. sync returns the same envelope after waiting up to wait_timeout_seconds (max 30). subscribe is identical to it: there is no SSE or WebSocket transport on the Developer API, and GET /v1/jobs/:id/events is a pull snapshot.

What should the step do instead?

Send the submit in async mode: it returns 202 with the job id and polling URLs, so the step ends in seconds and holds nothing. Poll in a later step, or use a webhook.

If a local timeout happens anyway, the docs are explicit: do not resubmit the original paid request. Read the job by id. A new submit creates a new paid job; see AI video API timeouts.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume