Rate Limits
Understand API and enhancement limits, how they are enforced, and how to handle them in your integration.
We limit the number of API requests and enhancements you can make in a given period.
This protects the platform from unexpected traffic spikes.
It also prevents runaway scripts.
It helps us keep performance fast for all customers.
Rate limits are standard automated measures.
They are tailored to your account type and volume.
They do not indicate a system failure.
Rate limits currently apply to new customers first.
Existing customers keep their current behaviour until we announce a change.
How limits are communicated
We do not send out-of-band notifications when a limit is reached.
Instead, the API communicates limits directly to your application.
Your integration should monitor for HTTP 429 Too Many Requests.
Your integration should also monitor for image error states.
Depending on the limit, the restriction may last for a few seconds, an hour, or longer.
The exact reset window depends on your account configuration.
Limit types and reset windows
Global API request rate
Up to 300 API requests per second per IP address.
The API returns HTTP 429 Too Many Requests.
The limit resolves instantly as traffic slows.
Duplicate file name protection
Up to 30 duplicate file names per hour for the exact same filename string.
The API returns HTTP 429 Too Many Requests.
The limit resets hourly.
Enhancement hard limit
By default, up to 500 enhancements per day unless your account has a custom limit.
Newly submitted images enter an error state.
The limit resets daily, or when your capacity is upgraded.
Global API request rate
Global limits apply across all endpoints.
They protect the core stability of the API.
You can make up to 300 API requests per second per IP address.
If you exceed this limit, the API returns HTTP 429 Too Many Requests.
The limit resolves as soon as traffic slows.
Duplicate file name protection
This safeguard catches faulty scripts that get stuck in retry loops.
These scripts often try to register the same image repeatedly.
You can register up to 30 duplicate file names per hour for the exact same filename string.
This applies when registering images or brackets.
If you exceed this limit, the API returns HTTP 429 Too Many Requests.
The limit resets hourly.
Ensure your application generates unique filenames.
You can also append unique hashes before registration.
If you hit this limit, do not keep retrying the same filename.
Enhancement hard limits
Enhancement limits govern complex compute-heavy processing tasks.
By default, the hard limit is 500 enhancements per day.
This is the absolute ceiling for throughput unless your account has a custom limit.
If you exceed this limit, newly submitted images enter an error state.
The status_reason field indicates that the image was rate-limited.
Images can be reprocessed once the limit window resets.
Images can also be reprocessed after a capacity upgrade.
Enhancement limits by account tier
Enhancement limits are tailored to your account type.
Compute requirements vary widely across customers.
Exact thresholds depend on your contract.
Limits generally scale across these profiles:
Testing / Trial Accounts have baseline limits for safe integration testing.
Essential / Standard Plans have limits for steady production usage and moderate bursts.
Enterprise Plans have custom elevated limits for very high-volume workloads.
Contact our team if you need to confirm your account's specific hard limit.
Developer best practices
Robust integrations anticipate rate limits.
They recover without manual intervention.
We recommend the following patterns.
Monitor for HTTP 429s
Configure your HTTP client to explicitly catch 429 Too Many Requests.
Do not treat these as generic 500 server failures.
Implement exponential backoff
When an API request returns 429, retry after a short delay.
If it fails again, double the delay before retrying.
For example, retry after 1 second, then 2, then 4.
This gives the platform time to process your traffic.
Check status_reason
status_reasonIf your integration uses polling or webhooks, always check status_reason on image errors.
This tells your application whether a hard limit was reached.
Throttle at the source
If your application generates large bursts of traffic, add short delays before dispatching requests.
This reduces avoidable limit errors during bulk uploads.
Need more capacity?
If you frequently hit hard limits, your workload has likely outgrown your current tier.
We are happy to review your usage patterns and help configure the right capacity.
Please reach out based on your current account status:
Leads and testing accounts should contact Sales or Support.
Essential / Standard plans should contact Support through in-app chat or email.
Enterprise plans should contact their dedicated Account Manager.
Last updated
Was this helpful?