JSON2VIDEO Documentation Rate limits & quotas
The usage limits on a JSON2Video account cap how much video you produce, not how fast you ask for it. Usage is metered in credits plus a few per-plan caps; there is no separate throughput or rate tier to buy.
What is metered
| Limit | What it caps | Set by |
|---|---|---|
| Credits | Total seconds of video you can produce | Your balance |
| Maximum render length | Duration of any single movie | Your plan |
| Movies / drafts (legacy plans) | Number of renders per period | Your plan |
Credits are the main one: 1 credit per second of output, at any resolution from SD to 4K. New accounts get 600 free. Failed renders are not billed. See Credit consumption.
Maximum render length caps a single movie — a plan with plenty of credits can still refuse a very long render. The per-plan figures are on the Plans page.
Movies and drafts counters apply only to older count-metered plans. Current plans meter time instead. GET /v2/movies returns whichever apply to you in remaining_quota, so you never have to guess:
"remaining_quota": { "time": 1807 }
When a quota runs out
Requests are rejected immediately rather than slowed down:
| Response | Message | Meaning |
|---|---|---|
400 |
Insufficient credits |
Balance is empty. Top up to continue. |
401 |
You exceeded the quota of movies in your plan. Please upgrade your plan to continue. |
A plan count limit, not a credit limit. |
403 |
account_suspended |
The account has been sitting without credits. Adding credits lifts it automatically. |
None of these is worth retrying — a retry fails the same way. Treat them as terminal and alert instead, as described in Error handling. Check remaining_quota before submitting a large batch.
Request rate
For normal use, the API's request rate is not a constraint you need to design around: a render is a single POST /v2/movies, and the traffic after it is status checking. Almost every account that worries about request volume is really worrying about polling.
Two habits keep you comfortably clear:
- Don't poll faster than every 5 seconds per render. Renders take considerably longer than that, so faster polling returns the same answer repeatedly and buys nothing.
- Better still, don't poll. Register a webhook and let us call you the moment a render finishes. One request per render instead of dozens.
When you submit a batch, spread the calls out rather than firing them all at once — it costs you nothing in wall-clock time, because the renders queue and run regardless.
High-volume and burst use
Renders run in parallel, and your throughput is governed by your credits and plan caps rather than by a queue you can see. That works well up to substantial volumes without any special arrangement.
If you are preparing something unusual — a launch, a bulk migration, a campaign that will produce far more video in a day than you normally do in a month — tell us in advance. We will confirm the capacity is there for you and, if your use case needs guarantees in writing, discuss what that looks like. The conversation is free and considerably cheaper than discovering a ceiling mid-campaign.