Quotas and limits

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:

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.