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

To help you evaluate Listen API, we provide a transparent and simple pricing model, andcomprehensive documentation for all API endpoints and sampleJSON responses

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 andmaintain. 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,002,639 podcasts and 153,026,581 episodes on the Internet. The volume of podcast contents grows faster and faster. You need to hostthe 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,002,639 podcasts and 153,026,581 episodes. You need to investin 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,002,639 podcasts and 153,026,581 episodes by keywords, then you have to build a search engine on your end. A search engine issimple on the UI, but extremely complex on the backend infrastructure. There must be a reason why Google, "a simple website", employs 175,000 full-timeemployees (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 linkbuilding. Such fake podcasts are not for human listeners to consume. You have to deploy both automatic and manual processes to make sure not toinclude 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 withfake 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 thesalary 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. Timespent 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 enginewebsite 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 andfix incorrect data. With the help of so many people around the world 24/7, we areable to maintain a high-quality podcast database.

Yes and yes.

blablabla

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 + allepisodes) 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'temploy 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.

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

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 withoutadding more servers.

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 andPRO plans), except for podcast/episode ids and pub_dates.

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

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 notbe 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

To find new jobs, we use four approaches.

First, we run crawlers 24/7 to find publicly accessible jobs on the Internet, which is similar to how Google or other search engines find new websites.

Second, users submit new jobboards to apijobs on their own -- we get hundreds of new submissions from user every month.

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 searchengine 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 fakepodcasts (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 ListenNotes.

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

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 FREEplan, especially using disposable email addresses; 2. Caching most of the response data on the server side. Please make sure you don't violate our APITerms of Use.

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'tneed 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 customizationswould 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 logoin the Uber app.

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

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 ourend, 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.

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 BubbleandRetool apps.

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

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 requestsare 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 ListenAPI. 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'sservers; 3) endpoints and parameters of API requests. Other than that, we know nothing about end users of the podcast app.

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.

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 runningListen API since 2017, this happens more often then we expected. Programmers are human beings. And human beings make mistakes. We don't want abad 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. Differentendpoints have different rate limits, because some endpoints are more compute intensive than others. A new API user gets relatively low rate limits, whichwill be increased over time.

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

How to report inappropriate / illegal content on Listen Notes?

How to remove my personal information from Listen NotesContent policies for Listen Notes

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