The Movie Database (TMDB) API - TV Section

The Movie Database (TMDB) API - TV Section is the Broadcasting catalog's breadth record: a community-built television metadata catalogue whose TV surface describes series, seasons, episodes, networks, production companies and people, delivered by Datadory as typed, joinable rows. One series record carries 26 documented fields - identity, the air-date spine, season and episode structure, network and studio attribution, lifecycle status and the community popularity-and-voting block.

Where the neighbours specialize, this one spans. TVmaze owns realtime schedules and future listings; TheTVDB owns ordering discipline and localization habit; this catalogue contributes breadth - more than 30 discovery filters and sort options across the whole TV catalogue, search that matches original, translated and also-known-as titles, and a catalogue-wide identifier roll covering every TV series and TV network, so backfills begin complete. Get a sample of this dataset to see the six entity levels laid against your use case.

Illustrative rows in the delivered shape - one record per series with the season tree, networks and credits hanging off the series identifier:

# delivered shape - one record per series, child entities keyed on the series id

id                : <tmdb series id>       name : <current title>
original_name     : <title in original production language>
original_language : en                     origin_country : [US]
status            : Returning Series | Ended | Canceled     in_production : true | false
first_air_date    : YYYY-MM-DD             last_air_date : YYYY-MM-DD
episode_run_time  : [minutes]              popularity : n.nnn
vote_average      : n.nn                   vote_count : n
number_of_seasons : n                      number_of_episodes : n

next_episode_to_air : {air_date, episode_number, season_number, runtime}
last_episode_to_air : {same fields, most recent aired episode}

seasons              : [{air_date, episode_count, name, overview, season_number, vote_average}]
networks             : [{name, origin_country}]     production_companies : [{name, origin_country}]
genres               : [{id, name}]                 created_by : [{name, gender}]

# catalogue-wide TV identifier roll - every TV series and TV network, ids only
<one compact record per series, one per network, ready to diff between pulls>

Read the anatomy rather than the angle brackets. Every series resolves through one identifier to its titles, its air-date window, its next transmission, its season tree and the networks and companies behind it - which is why a guide feature, an availability scan and a catalogue audit all key off the same spine. Live values for the networks, genres and franchises you name arrive with the sample in exactly this frame.

Twenty-two documented fields carry every delivered series record, grouped five ways: identity (id, name, original_name), the scheduling spine (first_air_date, last_air_date, next_episode_to_air, last_episode_to_air, episode_run_time), structure (number_of_seasons, number_of_episodes, seasons), attribution (networks, production_companies, created_by, genres, origin_country, original_language) and lifecycle-plus-reception (status, in_production, popularity, vote_average, vote_count). Definitions below were verified against the operator's own television documentation during the research pass, not inferred from sample payloads. Four further fields - poster and backdrop references, the marketing tagline and the series homepage - are defined on the same records but serve artwork and copy workflows, so they fold under additional fields on request, alongside episode-sub-resource detail.

Three groups do the analytical lifting. The scheduling spine answers when a programme ran and when it runs next: first_air_date and last_air_date bound the run, while next_episode_to_air and last_episode_to_air arrive as nested episode objects, making the record forward-looking. The attribution group carries the broadcast dimension - networks with each network's origin country, plus production_companies, created_by and genres. The reception block pairs popularity, vote_average and vote_count, where the vote count tells you how much weight the average can bear.

• Geography: Global. Language and region parameters localise titles and overviews, origin_country rides on every series, and each network entry carries its own origin country - a telenovela, a K-drama and a British sitcom resolve on the same field frame.
• Temporal: The full historical television catalogue, plus forward air dates through next_episode_to_air - rare among catalogues, which stop at what has already aired.
• Granularity: Six entity levels - series, season, episode, network, production company and person - joined by stable identifiers, with the catalogue-wide TV series and network identifier roll underneath.

That combination - global spread, forward dates, catalogue-scale identifiers - is why product teams reach for it. For who actually watched, the neighbours take over: BARB Weekly Top 50 Shows and Viewing Data measures UK audiences, and the Internet Archive TV News Archive holds 4.37 million caption-searchable news broadcasts.

API, files, or your warehouse. Daily, weekly, or hourly.

You pick the channel and the cadence; flattening the nested objects is our problem, not your pipeline's. Series records arrive with the season tree, networks and credits already typed and keyed on the series identifier, the catalogue-wide TV series and network identifier roll arrives as a flat companion extract, and consecutive deliveries diff cleanly because the field frame never moves between pulls. Warehouse loads write straight into your storage with the identifier spine intact, so a backfill and its increments always agree.

1. Competitive-intelligence and product teams treat the identifier roll and the next_episode_to_air objects as a change feed for new and upcoming series by network - a launch surfaces here before it surfaces anywhere measured - see competitive intel product teams use cases.
2. Developers and data-product builders assemble guides and discovery features on the identifier spine: one series id resolves titles, artwork references, season trees and credits - mapped in developers builders use cases.
3. Market researchers and consultants run content-availability landscape scans across countries and languages, using the language and region parameters to make catalogues comparable - workflows at market researchers use cases.
4. Journalists, academics and students pull programme facts - first and last air dates, season counts, statuses - with the operator named, instead of citing wikis of unknown provenance.
5. Data scientists prototype title-matching and catalogue-classification models on structured, multilingual metadata - see data scientists use cases.

Competitive-intelligence and product teams hold relevance 3 in Datadory's persona research: the identifier roll plus forward air dates behave like a change feed for new and upcoming series by network, and launches are legible before any measurement catches them.

Developers and data-product builders and market researchers and consultants sit at relevance 2 - builders wire guides and discovery onto the identifier spine once; researchers get comparable content-availability frames across markets. Sales and growth teams land at relevance 1 for account mapping against networks and studios, as do journalists, academics and students for fast programme-fact lookups and data scientists, whose training-set ambitions outrun what community-scored metadata should carry. Persona-by-persona workflows expand on the linked use-case pages above.

Within TV metadata, the trade-offs run on specialization versus span. TVmaze API - TV Show and Episode Database is the schedule-first option - the catalog's only quality-10 record, built around realtime grids and complete future listings. TheTVDB - TV and Film Metadata Database owns ordering discipline: absolute episode numbers, airs-before flags and the deepest alias and translation habit in the slice. This record's edge is breadth - more than 30 discovery filters, also-known-as title matching, and the identifier roll nothing else replicates.

Against the UK National Data Library / Find Open Data the contrast runs between metadata depth and government publication: 23 broadcasting-tagged UK public datasets there, global television description here - the head-to-head lives on our comparison page. The practical stack pairs this catalogue for identity and breadth with TVmaze for schedules and TheTVDB for ordering. Where everything ranks sits on the best broadcasting datasets ranking.

Four things worth settling upfront.

• Community-built, so coverage follows contributors. Mainstream English-language television is deep; some regional or brand-new programming carries thinner translations until someone adds them. Scope the sample to your networks and territories and the gaps surface immediately.
• The scores are community signals, not measurements. popularity, vote_average and vote_count describe attention and taste; pair with Barb or Ofcom when the question is who actually watched.
• The identifier roll is the quiet advantage. Starting a join from a complete catalogue-wide id list beats discovering your universe incrementally - say whether you want it in the sample.
• Six levels reward a named scope. Bring the networks, genres or countries you care about and the sample arrives cut to them; the field frame stays identical either way.

Because a metadata catalogue is only useful once its nesting is flattened and its identifiers hold still. Datadory delivers the six entity levels keyed on the series identifier, resolves the artwork references so images load without a second lookup, keeps the forward-air-date objects intact rather than trimmed away, and ships the catalogue-wide TV series and network identifier roll as a flat extract your warehouse can diff between pulls. Start with a sample of this dataset scoped to the networks and territories you nominate, then browse the rest of the slice on the broadcasting data hub or the best broadcasting datasets ranking.