Rate limiting

Rate limiting helps protect the Paddle platform and make sure it works smoothly for everyone. It works by putting a cap on the amount of requests that an IP address can make in a certain timeframe.

If you send too many requests, you'll get an error with a 429 response code.

1
2
3
4
5
6
7
8
1{
2  "error":{
3    "type":"api_error",
4    "code":"too_many_requests",
5    "detail":"You have exceeded the allowed rate limit, please retry your request after the number of seconds in the Retry-After header.",
6    "documentation_url":"https://developer.paddle.com/errors/too_many_requests"
7  }
8}

Our rate limits are designed to protect the Paddle 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 Paddle Seller Support team if you think you may exceed the limits.

Rate limits

Rate limiting may change. We'll communicate any changes in plenty of time on our developer changelog.

• All operations in the Paddle API are rate limited, except the preview transaction and preview prices operations.
• An IP address can make up to 240 requests per minute.
• If exceeded, subsequent requests return a 429 error.
• When you get a 429 error, that IP address can't make another request for 60 seconds.

Handle rate limiting

When you get a rate limit error, it includes a Retry-After 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.

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.

You can use the include parameter to get related entities when making a request, rather than making multiple requests. For example, you can include all related prices when getting a product:

Rather than sending requests in a loop, we recommend:

• Subscribing to webhooks to let you know when something's changed.
• 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 Paddle Seller Support team who can help.

Related pages