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 number 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.

429 - Too Many Requests

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

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.

Current rate limits

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

Platform rate limits

All operations in the Paddle API are rate limited.

An IP address can make up to 240 requests per minute.
If exceeded, subsequent requests return a too_many_requests error (429).
When you get this error, that IP address can't make another request for 60 seconds.

Pricing preview rate limits

The preview transaction and preview prices operations have a higher rate limit to support high-volume use cases like pricing pages.

An IP address can make up to 1,000 requests per minute to these endpoints.
If exceeded, subsequent requests return a too_many_requests error (429).
When you get this error, that IP address can't make another request to these endpoints for 60 seconds.

You can get localized prices client-side using the Paddle.PricePreview() and Paddle.TransactionPreview() methods without being rate limited.

Subscription rate limits

Additional limits apply when updating subscriptions that result in immediate charges. For example, upgrading a subscription using prorated_immediately or full_immediately as the proration_billing_mode with no credit balance available.

An account can make up to 20 chargeable updates to a subscription per hour, with a maximum of 100 per 24-hour period.
If exceeded, subsequent requests return a subscription_immediate_charge_hour_limit_exceeded or subscription_immediate_charge_24_hour_limit_exceeded error (429).
When you get these errors, you can't make another immediate charge for that subscription until the next hour or day.
These limits apply on a per-subscription basis to help maintain a good customer experience. There's no cap on the total number of immediate charges across all subscriptions.

Handle rate limiting

When you get a too_many_requests error, it includes a Retry-After response header to let you know how long to wait before retrying your request. Avoid making requests during this time.

Watch for too_many_requests errors and build a retry mechanism that runs when the limit has expired.

Avoid rate limiting

To reduce the risk of being rate limited and keep your integration performant, design it to use as few requests as possible.

Use the include parameter to get related entities in a single request rather than making multiple requests. For example, include all related prices when getting a product:

GET /products/{product_id}?include=prices

Rather than sending requests in a loop:

Subscribe to webhooks to let you know when something's changed.
Cache data you'll use again for a short period — especially in client-side applications.

If you're regularly being rate limited, contact the Paddle support team.