Creatomate 20% monthly credits per day vs Sume plan concurrency

Creatomate throttles by credits and request rate: about 20% of your monthly credits can be used in 24 hours, 30 requests per 10 seconds, and an unlimited queue. Sume throttles by plan concurrency instead: 1 to 20 jobs processing at once and a bounded queue, with 429 queue_full when the queue is full.

Creatomate's numbers are from its limits and concurrency page; Sume's are from the generation admission and authentication docs.

What are Creatomate's limits?

Creatomate's page says the API accepts 30 requests per 10-second window across all calls, and exceeding it returns 429 Too Many Requests. Concurrency depends on the subscription tier, and about 20% of monthly credits can be used within 24 hours: its example is a 200,000 credit plan allowing 40,000 credits a day. There is no limit on the queue size, and all renders eventually complete if you respect the rate limit.

The page does not state maximum duration or file size, and says to contact support for custom needs. Separately, file retention says rendered files are hosted for up to 30 days, after which the URLs go inactive, so move files to your own storage.

What are Sume's limits?

Sume separates request rate from capacity. Request rate is a per-minute write budget by plan (Free 120, Pro 300, Startup 600, Scale 1200) with a larger read budget. Capacity is the generation concurrency limit: how many paid jobs can be processing at once, with extra jobs accepted as queued.

What happens when you overshoot?

On Creatomate, overshooting the request rate gives a 429 and overshooting your daily credit share delays work, but the queue itself never refuses you. On Sume, concurrency being full is not an error: valid jobs are accepted as queued while capacity remains. Once concurrency plus queue is full, the next paid submit fails with 429 queue_full, which means waiting for a job to finish or cancelling one. Prepaid top-ups do not raise processing concurrency; the docs say it is plan-only.

Which of these applies to a given media route (for example Timeline renders) is stated by the docs as covering paid generation jobs, so read generation_limits on your own workspace instead of assuming.

How should a batch client behave?

For Sume, submit with an Idempotency-Key, treat queued as normal, and use a webhook or poll status_url. If you get queue_full, hold the batch and retry after any job completes. A small gate keeps you inside the queue.

import asyncio


async def run_batch(items, submit, limit: int):
    gate = asyncio.Semaphore(limit)

    async def one(item):
        async with gate:
            return await submit(item)

    return await asyncio.gather(*(one(i) for i in items))


async def main():
    async def submit(i):
        await asyncio.sleep(0.01)
        return i

    print(await run_batch(range(10), submit, limit=4))


asyncio.run(main())

Which is easier to plan around?

Creatomate's rule is a budget you can compute from your credits. Sume's rule is a ceiling you can read from the dashboard Concurrency tab, which the docs call the source of truth. Neither page publishes a per-render completion time, so measure your own.

What does the 30-day retention add?

Creatomate hosts every render for up to 30 days and then the URL, dashboard entry, status endpoint and snapshot image all expire, so a webhook that copies the file to your own storage is the safe pattern. Sume mirrors results into media.sume.com URLs and tells you to store those, but the docs I read do not state an expiry, so verify before treating them as archival.

Either way, treat provider hosting as delivery, not storage. Record the final URL, the job id and the time you copied the file.

• Creatomate: files hosted up to 30 days.
• Creatomate: 429 above 30 requests per 10 seconds.
• Sume: dashboard Concurrency tab is the source of truth.