What is the Transloadit Rate Limiter?
Transloadit’s Rate Limiter protects customers by allowing 250 Assembly creations per minute and 250 concurrent Assemblies by default. These limits can be adjusted upon request.
How the Rate Limiter works
Transloadit’s limiter places separate admission controls on how quickly Assemblies are created and how many remain active at once. The first protects the creation path over time, while the second caps outstanding processing, so satisfying one condition does not imply capacity under the other. It belongs in the client submission loop, where concurrency, queued work, retry delays, and anticipated traffic peaks should be managed together.
A client authenticates and submits files or references together with workflow instructions. The platform validates the request, schedules dependent operations, records state transitions, and exposes results through a response, polling endpoint, or notification.
Platform concepts become reliable only when their lifecycle is explicit. Authentication, idempotency, retries, timeouts, observability, quotas, and terminal states should be designed together rather than added after failures occur.
Key facts
- 1The default creation allowance is 250 Assemblies per minute. A bursty producer should pace submissions instead of assuming an equivalent number can be sent at any instant.
- 2The separate default concurrency ceiling is 250 Assemblies. Long-running work can hold that capacity even when the client’s recent creation rate is below its minute allowance.
- 3Both defaults can be adjusted on request. Capacity planning should happen before a known surge, because immediate retries after rejection add attempts without completing media work.
When the Rate Limiter matters
Keep submission concurrency within both limits or arrange an adjustment before a predictable traffic surge. Uncontrolled retries can intensify throttling and delay otherwise valid Assembly creation.
- Running repeatable upload, import, processing, AI, storage, and notification pipelines.
- Tracking long-running media work independently from an application request.
- Applying credentials, quotas, retries, and error policies consistently across integrations.
Working with platform at scale
Guidance that holds across every platform term in this glossary, not just the Rate Limiter.
What you gain
- Reusable workflows separate application intent from processing infrastructure.
- Stable job identifiers and lifecycle events improve observability and recovery.
- Managed queues and workers let products scale without embedding every media tool.
What it costs
- Synchronous responses are simple but keep connections open while long work executes.
- Aggressive retries improve recovery from transient faults but can duplicate work or overload a dependency.
- Higher concurrency reduces queue time until resource contention or a downstream limit becomes the bottleneck.
Answer these before production
- 1Define authentication, authorization, idempotency, retries, and terminal error behavior.
- 2Observe queue time, execution time, callbacks, and partial results with stable identifiers.
- 3Exercise malformed, duplicate, interrupted, and unauthorized requests before launch.
How Transloadit helps with the Rate Limiter
When the Rate Limiter is relevant to your workflow, you can hand the surrounding platform work to Transloadit instead of maintaining the processing stack yourself. Transloadit models file workflows as reusable Assembly Instructions. Upload, import, processing, AI, storage, delivery, status updates, and error handling can be composed without operating the underlying media tools yourself.
Support for a specific codec, container, parameter, or combination can vary by Robot and processing stack. Check the linked documentation for the exact inputs and outputs available for your use case.