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:
"faultstring": "Rate limit quota violation. Quota limit exceeded. Identifier : \_default",
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.
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 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
- When you get a 429 error, check the
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:
|The allowed quota count in total. Applies only to 200 OK responses.
|The available quota count in the quota interval. Applies only to 200 OK responses.
|The UTC time in milliseconds determines when the quota expires and a new quota interval starts. Applies only to 200 OK responses.
|Rate limit per minute.
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
retries = retries +1
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.
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.
- 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.
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 28 days ago