Vizard API rate limits by plan vs Sume's per-minute budget

Vizard lists API limits from 1 per minute (Free) to 10 (Business). Sume allows 120 to 1,200 writes per minute by plan, with reads budgeted separately.

4 min readSume
All posts

Vizard's pricing page lists API rate limits that start at 1 request per minute on the Free plan and reach 10 per minute on Business. Sume's write budget is 120 requests per minute on Free and 1,200 on Scale, so a repurposing batch that would queue for an hour on one service fits inside a single minute on the other.

The two numbers are not measuring the same thing. Vizard's limits are tied to a plan whose unit is a minute of source video; Sume's are request budgets, and what you pay per job is separate. This post only compares how fast you can submit work.

What each page lists

Figures below come from each provider's own page. Vizard shows limits per minute and per hour for each plan.

Sume publishes writes per minute per plan, reads at 40 times that, and notes that reads and writes have separate budgets.

API submission limits by plan (read 2026-10-03)
Provider and planPer minutePer hour
Vizard Free110
Vizard Creator320
Vizard Business1060
Sume Free (writes)120not listed
Sume Pro (writes)300not listed
Sume Startup (writes)600not listed
Sume Scale (writes)1,200not listed

What this means for a 40-clip batch

Forty submissions on Vizard Free take at least 40 minutes at one per minute, and the 10 per hour ceiling stretches that to four hours. On Business the 10 per minute pace gets 40 submissions in about four minutes, and the hourly cap of 60 still covers them.

On Sume the same 40 submissions are 40 writes, well under every plan's per-minute budget, including Free. Status checks are reads, and the read budget is 4,800 per minute on Free, so polling 40 jobs does not eat into the submit budget.

When a limit still bites on Sume

A 429 response carries a retry-after header and error.details.scope, so a client can tell which budget it hit. Concurrency is governed separately by the plan, so a burst of accepted jobs can still queue behind the plan's concurrent slots even when the request budget is fine.

Retry a 429 after the retry-after delay and reuse the same Idempotency-Key so a retry cannot create a second paid job. If you only need a handful of clips a day, none of this matters; the limits become the deciding factor when you submit hundreds in one run.

Takeaway

If your workflow is an API loop over many clips, compare submit budgets first and price second. Check the Vizard page for the current figures before you commit, since plan limits change.

Sources

Related posts

More in Comparisons

All Comparisons posts

Written by Sume