Quotas and limits
This page provides a comprehensive overview of the quotas and limits for the Programmable Image APIs. Understanding these limitations is essential for optimizing API usage and ensuring seamless application integration. Read on to learn about the different account types and their respective allowances and strategies for graceful handling and exponential back-off in case of rate limit violations.
Free account
For users on a free account, the API allows processing up to 50 credits during the demo run. Once this rate limit is reached, the API will return a 429 status code with the following error information:
{
"fault": {
"faultstring": "Rate limit quota violation. Quota limit exceeded. Identifier : \_default",
"detail": {
"errorcode": "policies.ratelimit.QuotaViolation"
}
}
}
Credits
If you have purchased Credits, you can utilize them without any limitations. This provides you with the flexibility to use the API according to your specific requirements, leveraging the purchased Credits as needed.
Subscriptions
Users with a subscription will be subject to a rate limit of 1000 requests per minute. This ensures a controlled and fair usage of the API's resources, preventing abuse and maintaining a stable service for all subscribers.
Rate limits
Rate limiting helps protect the Picsart platform and make sure it works smoothly for everyone. It works by putting a cap on the amount of requests that an account can make in a certain timeframe.
If you send too many requests, you'll get an error with a 429
response code.
Picsart can handle sales and high-volumes of traffic
Our rate limits are designed to protect the Picsart platform from abuse and maintain system stability. The limits are high enough to handle sales and promotions, along with other spikes in traffic. Contact the Sales team if you think you may exceed the limits.
Rate limiting may change.
We'll communicate any changes in plenty of time on our release notes.
- All operations in the Picsart API are rate limited.
- Each account can make 1000 requests per minute.
- If exceeded, subsequent requests return a
429
error. - When you get a 429 error, check the
X-Picsart-RateLimit-Reset-Time
.
Graceful handling
When you get a rate limit error, it includes a X-Picsart-RateLimit-Reset-Time
response header to let you know how long to wait before retrying your request. You should avoid making requests during this time.
To handle rate limiting, we recommend watching for 429
errors and building a retry mechanism that runs when the limit has expired.
To manage quotas and rate limits gracefully, you can utilize the following response headers returned by the API:
Response header | Sample value | Description |
---|---|---|
X-Picsart-RateLimit-Limit | 500 | The allowed quota count in total. Applies only to 200 OK responses. |
X-Picsart-RateLimit-Available | 499 | The available quota count in the quota interval. Applies only to 200 OK responses. |
X-Picsart-RateLimit-Reset-Time | 1678874406 | The UTC time in milliseconds determines when the quota expires and a new quota interval starts. Applies only to 200 OK responses. |
Quota-Available-Count | 20 | Rate limit per minute. |
Exponential back-off
Exponential back-off is an effective error-handling strategy that allows clients to retry failed requests with increasing time intervals between attempts. This helps avoid collisions when multiple clients attempt the same request simultaneously. Additionally, introducing jitter (randomization) in the time delay between requests further enhances the reliability of the retry mechanism.
Here's a pseudocode demonstrating one possible way to implement the exponential back-off strategy:
retry = true
retries = 0
WHILE (retry == TRUE) AND (retries \< MAX_RETRIES)
wait_for_seconds (2^retries + random_number)
result = get_result
IF result == SUCCESS
retry = FALSE
ELSE IF result == ERROR
retry = TRUE
ELSE IF result == THROTTLED
retry = TRUE
END
retries = retries +1
END
Scope
Rate limiting is applied in two ways: by application and by account. By default, the account scope is implemented, and the rate limit applies to the entire account. If you require application-specific rate limiting, please contact our Developer Support at the Help Center or Developer Support at Slack.
Avoid rate limiting
To reduce your risk of being rate limited and make your integration as performant as possible, it's good practice to design your integration to use as few requests as possible.
We recommend:
- Caching data that you'll use again for a short period — especially if you're building client-side applications.
If you're regularly being rate limited, contact the Sales team who can help.
Quota increases
If you need to increase any of your quotas or limits, please reach out to our Sales team. We'll be happy to assist you in tailoring the API usage to meet your specific needs.
Updated 4 days ago