Listen Notes Podcast API Rate Limits

Rate limits are restrictions that our API imposes on the number of times an API account can access our services within a specified period of time - specifically, per second and per minute.

Why do we have rate limits?

All mature and responsible APIs must have rate limits. Rate limits are a common practice for APIs, and they're put in place for a few different reasons:

• They help protect against abuse or misuse of the API. For example, a malicious actor could flood the API with requests in an attempt to overload it or cause disruptions in service (e.g., malicious hackers, terrorists, business competitors, etc.). By setting rate limits, Listen Notes can prevent this kind of activity.
• Rate limits help ensure that everyone has fair access to the API. If one person or organization makes an excessive number of requests, it could bog down the API for everyone else. By throttling the number of requests that a single user can make, Listen Notes ensures that the most number of people have an opportunity to use the API without experiencing slowdowns.
• Rate limits can help Listen Notes manage the aggregate load on its infrastructure. If requests to the API increase dramatically, it could tax the servers and cause performance issues. By setting rate limits, Listen Notes can help maintain a smooth and consistent experience for all users.

How do these rate limits work?

Rate limits are measured in two ways: requests per second and requests per minute. Rate limits can be hit across any of the options depending on what occurs first.

Rate limits are defined at the account level. All team members and all api keys of the same account share the same rate limits.

When you hit rate limits, you'll get http 429 errors.

Our API is primarily designed to build interactive apps where API requests are initiated from human users, e.g., manually typing in a search query then triggering an API request. Therefore we set reasonable rate limits for such use cases. If you expect to batch scrape our data, then our API is not a good fit. You should check out our batch export tools.

What are some steps I can take to mitigate rate limits?

One easy way to avoid rate limit errors is to automatically retry requests with a random exponential backoff. Retrying with exponential backoff means performing a short sleep when a rate limit error is hit, then retrying the unsuccessful request. If the request is still unsuccessful, the sleep length is increased and the process is repeated. This continues until the request is successful or until a maximum number of retries is reached. This approach has many benefits:

• Automatic retries means you can recover from rate limit errors without crashes or missing data
• Exponential backoff means that your first retries can be tried quickly, while still benefiting from longer delays if your first few retries fail
• Adding random jitter to the delay helps retries from all hitting at the same time.

Note that unsuccessful requests contribute to your per-minute limit, so continuously resending a request won’t work.