Listen API : API de recherche et de répertoire de podcasts

API de recherche et répertoire de podcasts, simple et pratique. Recherchez les métadonnées de 653,882 podcasts et 42,115,434 épisodes par personnes, lieux ou sujets. C'est la même API qui fait fonctionner ce site Web.
Des questions? [email protected]
Updated: 2019-03-25

Pricing & Quotas

It's freemium model & pay as you go. You can find pricing details here.
If you use Listen API to build side projects for fun, it's unlikely that you'll exceed the quota limit. The headers of each API response includes usage numbers that you can check in your code.
In addition to higher quota limit, paid plans also provide:
  • higher-resolution podcast artwork images (1400x1400) than the free plan's (150x150)
  • social accounts (i.e., Twitter, Facebook, Instagram, LinkedIn, WeChat) and urls (i.e., YouTube, Spotify, Google Play, url1, url2, url3) of podcasts in the "extra" field of the API response, which is the same information as in the "ELSEWHERE" card of the podcast page (Example)
  • The first couple API requests may be extremely slow, which is likely a problem on the RapidAPI (the API gateway that Listen API uses) side. Once you get through the first couple requests, it'll be okay.
  • Using Listen API signifies your acceptance of the API Terms of Services below.
  • Check out this demo project using Django, React, and Listen API: ListenApiDemo
  • Use as the base url, instead of Why? We have 100% control over If there's outage on RapidAPI's servers, we can quickly switch to point to other backup API gateways.
  • If you need custom plans that are bigger than MEGA ($100/month), please contact us: [email protected]

Check quotas in code

The headers of each API response includes usage numbers that you can check in your code, which look like this:
X-RateLimit-directory-apis-Limit: 1000
X-RateLimit-directory-apis-Remaining: 765
X-RateLimit-full-text-search-quota-Limit: 1000
X-RateLimit-full-text-search-quota-Remaining: 521
X-RateLimit-typeahead-quota-Limit: 10000
X-RateLimit-typeahead-quota-Remaining: 6207
Sending HEAD requests doesn't count against the quota limit, which can be used to check X-RateLimit-* headers and to prevent exceeding the quota limit -- you may want to have some kind of caching mechanism here to avoid making too many HEAD requests: example code snippet.

API Terms of Services

Logo Requirements
If your application displays data fetched from Listen Notes API, you must show a "Powered by Listen Notes" logo on the same screen / page with that data. You can download the "Powered by Listen Notes" logo here.
Pre-Fetching, Caching, or Storage of Content
Applications using the Listen Notes API must not pre-fetch, cache, index, or store any Content on the server side.
Note that the id of podcast / episode, used to uniquely identify a podcast/ episode, is exempt from the caching restriction.


1. Why do I have to use Listen API?

Well, you don't have to. You have two choices:
You can hire an engineer (or multiple engineers) to build and maintain a podcast database. Or you can use Listen API. Which is cheaper?

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

Building a decent podcast database is an ongoing effort. It's not hard. But it takes time (and money) to build and maintain. Just like owning a car or a house, the initial expense to buy is way less than the ongoing cost to maintain (e.g., tax, insurance, unexpected costs...). As a grownup, we all know that.
There are new podcasts & new episodes being produced every second. Actually, there will be more and more podcasts being produced at a faster and faster speed -- we clearly see this trend from our database. To keep your database up-to-date, you have to run crawlers 24/7.
Of course, you need to pay for servers that run 24/7. You need to run crawlers, host your podcast database, and run a search engine like Elasticsearch on those servers. Do your own math by looking at AWS EC2 pricing.
You need to deal with edge cases to make sure your podcast database is high-quality. Let me give you some ideas: 1) A lot of podcast RSS feeds are malformed. 2) Podcasts change their RSS feeds from time to time. 3) A lot of podcasts are junk (e.g., machine-generated contents) that you don't want them to be in your database. 4) Podcasts may change audio urls, which actually happens a lot. 5) You need to deal with duplicate podcasts and episodes. At first glance, these edge cases seem trivial if you don't have much previous experience working in the internet industry. Oftentimes, you'll learn lessons in a hard way. Don't worry. We all need to start from somewhere or nowhere :)
What's worse, server outages may happen. Even Amazon or Google has large scale outage from time to time. It takes time, energy, money, and expertise to deal with those outages.
Actually, I haven't mentioned the most expensive part of building your own podcast database: opportunity cost. You need to decide where to spend your money and your developers' time: building your own podcast database, or building your apps. Using Listen API allows you to jumpstart the most exciting part of your project immediately.

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

Yes. Listen API powers our user-facing website Listen API benefits from most backend improvements of

4. If we use Listen API and it goes away in the future?

Your concern is valid. We all know that NOT ANY online services or companies can last forever.
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 latest database dump (all podcasts + all episodes) at a reasonably low price.
It's very likely that Listen Notes will outlive many well-funded startups or even public companies. I am able to 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 and it's unlikely that our company will shut down due to internal power struggle. I'm able to architect the software infrastructure to be robust enough while not wasting tons of money on server bills. If you've ever worked in any modern internet companies, you know that it's very easy to burn money on servers.

5. Do you provide any support?

Yes. If you have any questions about Listen API, just email [email protected].
Unlike talking to an average customer service guy in other lame companies, you talk to me directly. I'm the founder and CEO of Listen Notes, Inc. and I'm the person who built this whole thing by hand & by heart.
For API users, I reply emails almost instantly when I'm awake. "We are not a large House, we are a proud one" :)

6. If my app becomes so successful, will you copy my idea?

I'm not interested in building apps. Period.
If you've got any real experience working in the tech industry, you should know that ideas are cheap and execution is everything. Here's my suggestion: Actually, you shouldn't build anything. Go find a 9 to 5 job and retire there. Look, Google reads your emails from your Gmail account. Google can copy your ideas. If you use AWS, then Amazon has the God's view and Amazon can copy whatever you do. You should never launch any apps. Otherwise, any companies can copy your ideas.
If you think your ideas are original or unique, it's likely that you don't read enough books or listen to enough podcasts :)

API Endpoints

Read docs on RapidAPI
Use as the base url, instead of Why? We have 100% control over If there's outage on RapidAPI's API gateway servers, we can quickly switch to point to other backup API gateways.