Listen API FAQs

1. Why do I have to use Listen API? Why would I use this over the iTunes API? 🔗

You always have other options: Build and maintain your own podcast database, or choose other podcast APIs on the Internet.

To help you evaluate Listen API, we provide a transparent and simple pricing model, and comprehensive documentation for all API endpoints and sample JSON responses.

We make it very easy for you to try out Listen API. You don’t have to speak with any sales people, and we don't require you to "request a demo". You simply subscribe to a FREE plan without entering credit card info and start using Listen API.

If you subscribe to the PRO or ENTERPRISE plan, whenever you have any questions, you can get quick answers by emailing hello@listennotes.com -- you'll talk directly to the founder & CEO of Listen Notes.

How about iTunes API from Apple? It would be helpful to read through iTunes API's documentation and try it out on your own. You'll find that iTunes API may not be a good fit, because

it doesn't provide enough API endpoints / structured response data for you to build some basic product features (e.g., search all episodes, play audio, curate playlists...) - please read iTunes API's documentation, and you'll know within a few minutes;
it doesn't return a lot of search results of podcasts and the ranking is far from ideal;
its terms of service may not allow you to do what you want to do - again, please read iTunes API documentation, and you'll know within a few minutes;
it's likely that the API is not actively maintained and improved by their best employees, because it's not an important product in Apple Inc.;
when using an enterprise API, customer support from real human beings (i.e., support engineers) is usually part of the service - good luck getting timely and informative responses from Apple Inc. employees.

We've got a blog post that may be useful to you: How to evaluate a 3rd party RESTful API?

2. How hard could it be to build a podcast database? 🔗

Building a decent podcast database is an ongoing effort. It's not difficult. But it takes time and money (for server costs, engineer salaries...) to build and maintain. Just like owning a car or a house, the initial expense to purchase the item is much less than the ongoing costs to maintain it, due to tax payments, insurance expenses, unexpected repair needs, and most importantly, your time.

There are a few things you need to consider before building and maintaining your own podcast database:

There are at least 3,790,295 podcasts and 191,514,580 episodes on the Internet. The volume of podcast contents grows faster and faster. You need to host the data on your end and make sure the data is up-to-date.
Podcasts change rss feeds and audio urls more often than you expect, when considering 3,790,295 podcasts and 191,514,580 episodes. You need to invest in automatic tools and manual processes to clean up data 24/7, which are necessary but invisible to your users.
If you need to search 3,790,295 podcasts and 191,514,580 episodes by keywords, then you have to build a search engine on your end. A search engine is simple on the UI, but extremely complex on the backend infrastructure. There must be a reason why Google, "a simple website", employs 175,000 full-time employees (as of 2022) and another hundreds of thousands of contractors.
There are a lot of fake podcasts on the Internet (e.g., machine-generated audio). Sneaky Black Hat SEO people create tons of fake podcasts for link building. Such fake podcasts are not for human listeners to consume. You have to deploy both automatic and manual processes to make sure not to include fake podcasts in your podcast database. Fun fact: Google has a dedicated web spam team, and we also allocate a bunch of resources to deal with fake podcasts at Listen Notes.
If you need the database and the search engine to be up and running 24/7, you have to do work to make sure that servers won't have outages.
How much would you pay for a competent full-time software engineer? Would you rather pay for a third party cloud service (e.g., our API) or to pay the salary of several in-house software engineers?

In all honesty, the most expensive part of building and maintaining your own podcast database is the opportunity cost. It's about making a choice. Time spent building your own podcast database is time that you can't use to build your apps or websites.

Using Listen API allows you to jumpstart the most exciting part of your project immediately. In addition, we run a very popular podcast search engine website listennotes.com. There are over 2,000,000 people using our website every month, who play an important role to keep our podcast database up-to-date. For example, our website visitors help submit missing podcasts and fix incorrect data. With the help of so many people around the world 24/7, we are able to maintain a high-quality podcast database.

3. Are you actively supporting the API? Do you expect to continue doing so? 🔗

Yes and yes.

Listen API powers our user-facing website ListenNotes.com. Listen API also benefits from most backend improvements of ListenNotes.com.

We've been around since 2017 and we plan on being around for a long time.

4. What if we use Listen API and it goes away in the future? 🔗

Your concern is valid. We all know that NO online services or companies can last forever. For example, Google kills a lot of their own products.

If we decide to shut down Listen API, we’ll give you (at least) 12 weeks’ notice and you’ll be able to buy the most current database dump (all podcasts + all episodes) at a reasonably low price.

Listen Notes will probably outlive many well-funded startups or even public companies. We run Listen Notes lean. Unlike other bigger companies, we don't employ tons of people, so we don't need to pay tons of salaries - that means it's unlikely that our company will shut down due to an internal power struggle. We are able to architect the software infrastructure to be robust enough while not wasting tons of money on server bills.

5. Do you provide any support? 🔗

Yes. If you subscribe to the PRO or ENTERPRISE plan, just email hello@listennotes.com for any API-related questions. Occasionally we may answer questions from FREE users. However, we have to prioritize serving PRO/ENTERPRISE users.

Unlike tracking down lame customer service reps in other companies, you’ll speak directly with the founder and CEO of Listen Notes, Inc., who built this whole thing by hand & by heart.

6. We'll use tons of API requests. Are you able to support our scale? 🔗

Right now, there are companies doing tens of millions of requests/month with Listen API. We can easily support at least 10x of current traffic without adding more servers.

We apply best practices of infrastructure operations, with great monitoring & alerting in place. If there is something wrong with the API infrastructure, we are able to troubleshoot and fix as soon as possible. We've got a pretty good track record, in terms of system performance and uptime.

7. Can we cache the API response on the client side (e.g., inside the app or web browser)? 🔗

Yes. Our API Terms of Use (FREE and PRO plans) allows you to cache the response data on the client side, but you can't cache on the server side (FREE and PRO plans), except for podcast/episode ids and pub_dates.

In other words, you can permanently store only podcast/episode ids and pub_dates on the server side, e.g., in your own database. This "no caching" policy is very common for data APIs, e.g., Google Maps API (In-page search "No Scraping").

For the actual audio files of podcasts, you can store them on your server and process them (e.g., creating audio clips, speech-to-text...).

If you subscribe to the ENTERPRISE plan, you are allowed to cache the full response data on your servers.

8. In the API response, why are audio URLs from the listennotes.com domain? 🔗

To be clear, we don't store audios on our own servers. Podcasters will get accurate analytics data, e.g., the listener's ip address, user-agent...

We wrap the actual URLs with our own URLs (HTTP 301), e.g., audio.listennotes.com/e/p/997c4db8bd224df78f0716a3a8c05f5d, because podcasts often change audio URLs, and we want to help you and your users figure out the correct URLs.

It's a common practice for apps to cache data on the client side for performance optimization. Apps cache the permanent Listen Notes URLs on the client side, while we figure out the correct audio URLs from the server side. We constantly check to determine if podcasts change their audio from our end.

9. What if we can't find a particular podcast? What if the data is not in sync with the RSS feed (e.g., broken audio or incorrect podcast metadata)? 🔗

Although our podcast database is very comprehensive, it's possible that we don't add some new shows in time. This is similar to the fact that you may not be able to find new websites on Google, because it takes time for Google's crawlers to find and index new websites. In this case, you can help submit the missing shows.

It's also possible that the podcast creator changes the RSS feed and we don't catch the changes in time, or there are errors in the RSS feed. This is similar to the fact that you may click on some 404-ed (or outdated) web pages from Google's search results. It takes some time for Google to fix broken web pages from their search results. You can report metadata errors to us via hello@listennotes.com, and we'll fix as soon as possible (typically within minutes). Or you can use some self-service tools to help fix metadata errors on your end - be a good citizen :)

10. How do you make sure your podcast database is up to date? 🔗

To find new podcasts, we use four approaches.

First, we run crawlers 24/7 to find publicly accessible podcasts on the Internet, which is similar to how Google or other search engines find new websites.
Second, podcasters submit new shows to Listen Notes on their own -- we get hundreds of new submissions from podcasters every day.
Third, if we (Listen Notes employees) see any missing podcasts, we manually add them to our database. In addition, we run a very popular podcast search engine website listennotes.com. There are over 2,000,000 people using our website every month. Any of them can submit missing shows to Listen Notes, which makes our podcast database comprehensive and up-to-date. Please note that we manually review every podcast submission and reject fake podcasts (e.g., machine-generated audio).
Fourth, we partner with major podcast hosting services, who integrate with our podcast API to allow podcasters to submit new shows directly to Listen Notes.

We check the RSS feed of all podcasts 24/7. For recently-listened podcasts (based on our website and API traffic), new episodes would be added to our database within 1 hour (typically within 15 to 30 minutes). For other podcasts, new episodes would be fetched within a few hours - typically 2 to 4 hours.

11. What if we violate API Terms of Use? 🔗

Your account will be suspended if you violate our API Terms of Use. You can email us to appeal: hello@listennotes.com

The two most common cases that an API user gets suspended are the following: 1. Creating multiple accounts to get around the quota limit of the FREE plan, especially using disposable email addresses; 2. Caching most of the response data on the server side. Please make sure you don't violate our API Terms of Use.

12. Do we have to display the Listen Notes logo in our app even if we use a paid plan? 🔗

Yes. Our API Terms of Use is for all FREE/PRO API users. You only need to display "Powered by Listen Notes" on one screen that uses our data. You don't need to do it for every screen. You are allowed to place our logo below the fold, so it won't be too intrusive to your users.

We don't make any exception for any FREE/PRO API users, no matter if you are an individual developer or a public company. Those one-off customizations would increase the operational complexity on our end, which would take away our time that could've been used to improve the core products.

Displaying attribution is a common policy for data APIs. For example, as with Google Places & Maps APIs. Uber uses Google Maps in their app. There is a big Google logo in the Uber app.

If you subscribe to the ENTERPRISE plan, we can be flexible on the logo requirement.

13. Can we discuss our partnership by phone? 🔗

Listen API is designed to be self-service. If you can't figure out what Listen API can do and how to use it within a few minutes, then it's the failure on our end, which means we haven't done a good job explaining things. If you have any questions, let's chat via email first: hello@listennotes.com

You'll get informative answers via email from us much much faster than scheduling a phone call.

14. Can I use Listen API on no-code platforms? 🔗

Yes, as long as the no-code platform of your choice allows to connect to a REST API. For example, you can use Listen API to search podcasts on Bubble and Retool apps.

You may just want to embed playable podcasts, episodes, clips, or playlists to your website or blog. In this case, you don't need to use Listen API. You can easily embed playable podcasts to WordPress, Blogger, Ghost, Google Sites, Tumblr, and many other publishing platforms.

15. Do you provide language-specific libraries for the podcast API? 🔗

Yes. We have some. In the future, We will add libraries for more languages.

16. What information does Listen Notes collect from API users? 🔗

We collect minimum amount of information about the device that directly sends API requests to our servers, including 1) the device's IP address; 2) user-agent; and 3) endpoint and parameters of API requests. This is essentially the log line in Nginx access logs. That's it.

For example, a developer uses our API to build a podcast app, and a bunch of end users listen to podcasts using this podcast app. Typically, API requests are sent from the developer's servers, not from the podcast app. In other words, the developer's servers act as a proxy between the podcast app and Listen API. Therefore, we track only 1) IP addresses of the developer's servers that send API requests; 2) user-agent (e.g., python-requests) from the developer's servers; 3) endpoints and parameters of API requests. Other than that, we know nothing about end users of the podcast app.

17. Does Listen API have rate limits (e.g., N requests per second)? 🔗

Yes. We set reasonable rate limits for our API endpoints. If you use our API correctly, you may not even know the rate limit exists.

Every serious REST API in the world must set a rate limit - Google "api rate limit". If an API doesn't have rate limits, it would be easily DDoS-ed. For example, a programmer may send tons of API requests in a short amount of time from a tight loop (or even worse, an infinite loop). From our experience of running Listen API since 2017, this happens more often then we expected. Programmers are human beings. And human beings make mistakes. We don't want a bad user to bring down our whole system and affect other API users.

For Listen API, the FREE plan has a low rate limit, the PRO plan has a higher rate limit, and the ENTERPRISE plan has the highest rate limit. Different endpoints have different rate limits, because some endpoints are more compute intensive than others. A new API user gets relatively low rate limits, which will be increased over time.

18. Do you handle podcast deletion requests for DMCA, GDPR, and similar laws? 🔗

Yes. We take care of content deletion requests. Learn more:

You can redirect content removal requests on behave of your users to Listen Notes via the following API endpoint: DELETE /podcasts/{id} (or simply redirect such requests to hello@listennotes.com).

19. Can I legally stream podcast audio on my apps or websites using Listen API? 🔗

Absolutely, you can legally stream podcast audio on your apps or websites using Listen API. Learn more here.

Should the App Store reject your app because of its integration with our API, we are here to assist you.