Pp Plexctl

Plexctl — Printing Press CLI

Prerequisites: Install the CLI

This skill drives the plexctl-pp-cli binary. You must verify the CLI is installed before invoking any command from this skill. If it is missing, install it first:

1. Install via the Printing Press installer. It defaults binaries to $HOME/.local/bin on macOS/Linux and %LOCALAPPDATA%\Programs\PrintingPress\bin on Windows:

   npx -y @mvanhorn/printing-press-library install plexctl --cli-only
   

2. Verify: plexctl-pp-cli --version
3. Ensure the reported install directory is on $PATH for the agent/runtime that will invoke this skill.

If the npx install fails (no Node, offline, etc.), fall back to a direct Go install (requires Go 1.26.6 or newer). This installs into $GOPATH/bin (default $HOME/go/bin), so add that directory to $PATH instead:

go install github.com/mvanhorn/printing-press-library/library/media-and-entertainment/plexctl/cmd/plexctl-pp-cli@latest

If --version reports "command not found" after install, the runtime cannot see the binary directory on $PATH. Do not proceed with skill commands until verification succeeds.

API Info

Content Types

The API supports responses in both XML and JSON, and clients can request one or the other using the standard Accept HTTP header. The default is XML, so JSON will only be returned if it's explicitly requested (Accept: application/json). New applications should use JSON.

Throughout the docs, it's common for a examples to be given in JSON only since the JSON response would be preferred for new applications.

Headers

PMS accept a variety of custom headers that follow the pattern X-Plex-{name}. The full set of headers isn't enumerated here since some may only apply to certain endpoints, but common headers that can be included on all requests include:

X-Plex-Client-Identifier is typically required, as is X-Plex-Token for authentication.

There's no standard way to send non-ASCII values as HTTP headers. We attempt to recognize and parse UTF-8 and ISO-8859-1. If you're sending something that may include non-ASCII characters (often X-Plex-Device-Name), use UTF-8 if possible.

These are referred to as headers throughout documentation, but all X-Plex- headers can also be sent as query string arguments.

Auth

Most endpoints require token based authentication, and the token is expected to be sent in the X-Plex-Token header. Tokens are obtained from plex.tv. See the Authenticating with Plex section.

Paths and Keys

Many parts of the API reference things that can be fetched by their key. These keys follow a sort of relative URL resolution pattern. Some examples will help clarify.

• For a request to /library/sections that includes an item with a key of home in the response, that item can be fetched at /library/sections/home.
• For a request to /library/sections/home that includes an item with a key of /library/metadata/deadbeef in the response, that item can be fetched at /library/metadata/deadbeef.

We say this follows a "sort of" relative URL resolution pattern because all requests are treated as though they have a trailing slash.

/library/sections/ + home => /library/sections/home
/library/sections + home => /library/sections/home
/library/sections + /library/sections/home => /library/sections/home

Just like URL resolution, keys may contain absolute URLs as well, especially absolute https://... URLs or custom view://... URLs. In these cases the key resolved by simply using it, the parent is irrelevant.

Also note that the features described in this API can generally be present at a different paths. The /media/providers path defines where all features can be found. Note that a PMS can contain multiple providers which will be enumerated here. For simplicity, these docs use the most common, default paths. But when we say that /library/sections/{id} is part of the API, what we really mean is that a endpoint exists which is composed of the key for the content feature and the key for the library section.

Finally, it's worth noting that many paths can potentially be discovered by walking API responses and fetching keys, but paths that aren't documented here aren't part of the API contract, they just happen to exist for a particular provider. For example, a particular content directory might include a directory with key={baseLibraryPath}/genre. That's not an official part of the API that's guaranteed to exist for every content directory, it's just a key that happened to exist within that content directory.

Types

Many elements throughout the API have a type attribute. These types are meant to give helpful information, such as whether something is a movie library or a TV show library. Some API elements rely on a type number so both are provided below

List of Metadata Types

When an element has both type and key attributes, the type describes what will be returned when fetching that key. Some types will return a list of other elements. That list may have a Meta element describing the specific types within the list. Consider the following examples:

[
  {
    "key": "/foo",
    "type": "movie",
    "title": "A Movie"
  },
  {
    "key": "/bar",
    "type": "collection",
    "title": "My Favorite Movies"
  },
  {
    "key": "/baz",
    "type": "show",
    "title": "A Show"
  }
]

In each case, the type describes what will be returned when fetching the key. One exception is the /children key for parents like shows and seasons. It will return a list of children even though the type describes the parent.

Some elements may also include an optional subtype attribute. The subtype is meant to be a refinement of the type, not a completely different type. One test is trying to explain the type in natural language. type="clip" subtype="news" passes the test that "This is a clip, a news clip specifically." Another test is considering the client UI. A client should be functional if it ignores the subtype, and optimized if it respects it. If type="track" subtype="podcast", a client can successfully play the podcast in an audio player based purely on the type, but it may tweak the display or which advanced playback controls are visible based on the subtype.

List of Metadata Subtypes

• podcast
• webshow
• news
• photo

Collection Subtypes

• movie
• show
• artist
• album

Extras Subtypes

• trailer
• deletedScene
• interview
• musicVideo
• behindTheScenes
• sceneOrSample
• liveMusicVideo
• lyricMusicVideo
• concert
• featurette
• short
• other

Sources

Source URIs and attributes make it possible to uniquely reference content outside the local server context without requiring a fixed url. This might be desirable when showing related albums from a friend's shared media server, building a universal play queue, or returning aggregated hubs that span multiple providers. Source components are immutable and act as pointers to a single item or directory in the Plex ecosystem.

A source URI from a media server uses the server scheme while a cloud provider uses the provider scheme.

server://{SERVER_ID}/{PROVIDER_ID}/{PATH}
provider://{PROVIDER_ID}/{PATH}

As a single regular expression, that's:

/^(server|provider):\/\/([a-fA-F0-9-]+)?\/?([^/]+)([^\?]+)\??(.*)?/

The server id is the server's machineIdentifier. The provider id is the provider's identifier. The rest of the path represents the path of the content at the provider and may include additional query parameters like X-Plex- headers or media query syntax for sorts and filters.

Some examples may be helpful:

server://546684a3d18ac5c39037360ec9ce900b7af9cc36/com.plexapp.plugins.library/library/metadata/2814936
provider://tv.plex.provider.podcasts/library/sections/audio/all

The source attribute has the same structure as the source URI, but omits the path.

{SOURCE_TYPE}://{SOURCE_ID}/{PROVIDER_ID?}

/^(server|provider):\/\/([a-fA-F0-9-]+)?\/?([^/]+)$/

source="server://546684a3d18ac5c39037360ec9ce900b7af9cc36/com.plexapp.plugins.library"
source="provider://tv.plex.provider.podcasts"

Source attributes can be used as a base and combined with key or other root-relative path components to construct unique source URIs.

Pagination

Many endpoints that return a list of items support pagination. Additionally some endpoints will force pagination and limit number of elements returned if the client attempts to request all items. To request a specific subset of data, add two headers to specify the starting offset and the number of desired items.

• X-Plex-Container-Start - The desired starting offset
• X-Plex-Container-Size - The desired number of items

Both headers should be sent in order to request paginated content. Note that it's possible to request a size of 0 on supported endpoints in order to learn the total size without actually getting any content.

The response must be checked to see if the response is in fact paginated. The response might not be paginated at all, or it might include a different number of items than what was requested. A paginated response will include the headers:

• X-Plex-Container-Start - The offset of the first returned item
• X-Plex-Container-Total-Size - The total size of the collection (optional but typically present)

The response body will also typically include pagination info. If the response is a MediaContainer, then it will have offset and size attributes representing the start index and the number of items in the current response along with an optional totalSize attribute for the total number of elements in the collection.

HTTP/1.1 200 OK
X-Plex-Container-Start: 2
X-Plex-Container-Total-Size: 5
Content-Type: application/xml

{
  "MediaContainer": {
    "size": 3,
    "totalSize": 5,
    "offset": 2,
    "Metadata" : [
      …
    ]
  }
}

Rather than requesting a page starting at an index, it is also possible in some lists to request a page centered on a specific item in the list.

• X-Plex-Container-Focus-Key - The key of an item to center on
• X-Plex-Container-Size - The desired number of items

The requested size is respected regardless of the position of the focus item in the list. If the item is at the start of the list and 10 items are requested, 9 items in the response will be after the item. If the item is in the middle of the list and 10 items are requested, 4 items will be before the item and 5 items will be after.

Endpoints that support rich media queries also have a limit parameter that interacts with pagination. Sending limit in a query string limits the desired number of items, much like the X-Plex-Container-Size header. There are two major differences:

1. When using limit, the total size of the collection is not returned. The minimum of the limit and the actual total size will be returned as the total size.
2. The request may be more efficient when using limit, since the total size doesn't have to be known.

If the total size of the collection isn't needed, use limit, since the request may be more efficient.

Note that limit and X-Plex-Container-Size aren't mutually exclusive. You can page within the results that are bounded by the limit. If you want a total of 1000 items from a collection of many thousands of items, but you want to page through them 20 at a time, you'd use limit=1000&X-Plex-Container-Size=20&X-Plex-Container-Start=0.

API Versioning

PMS has never used API versioning before the creation of this document. The first published API is considered 1.0 with the API prior to publication considered 0.0. A client species its version via the X-Plex-Pms-Api-Version header on requests. If no header is provided, the version 0.0 is assumed.

API Changes

• 1.0.0 (Supported in PMS >= 1.41.9)

• Added /downloadQueue endpoints.

• Public release of API.

• The includeFields parameter has been renamed to includeOptionalFields. The includeFields parameter now means "include only these fields" where in the past it meant "please add these fields you wouldn't normally include." This was changed to be consistent with the cloud provider API.

• 1.1.0 (Supported in PMS >= 1.42.0)

  • Added ability to filter '/media/providers/metadata' endpoint by metadata types (PM-3702)
  • Changed types in /playlists/{playlistId}/items to array of integers.
  • Document the /photo/:/transcode endpoints
  • Fixed serialization of MetadataType objects for '/media/providers/metadata' calls.

• 1.1.1 (Supported in PMS >= 1.42.2)

  • Added 'metadataAgentProviderGroupId' query param to create and edit library section (PM-3577)
  • Fixed Add library section method type.

• 1.2.0 (Supported in PMS >= 1.43.0)

  • Added 'squareArt' as additional element type for image assets (PM-2959)
  • Added /media/providers/metadata endpoints (PM-1012)
  • Added delete method for /library/metadata/{id}/{element} (PM-4094)
  • Added documentation for Metadata-type Media Providers (PM-3051)

• 1.2.1 (Supported in PMS >= 1.43.1)

  • Added /tv.plex.providers.epg.{identifier}:{deviceId} endpoints (PM-4017)
  • Added new state to itemsGeneratorItems endpoint (PM-3475)

• 1.2.2 (Supported in PMS >= 1.43.2)

  • Added audioLayout endpoint (PM-5118)
  • Added videoCodec, audioCodec, and subtitleCodec endpoints (PM-5117)

Response Customization

Many endpoints allow the data that is included in the response to be tailored to exactly what the client wants. This is possible by either specifying things that should be excluded or the set of things that should be included. PMS's ability to include/exclude elements and fields is currently limited but expanding so this should be used with care.

Attributes can be customized by using a query string arg of either excludeFields or includeFields. This single parameter should be a comma-separated list of attribute names. For example, a request with excludeFields=summary,tagline is asking for the summary and title attributes to be left off any metadata items while the includeFields parameter indicated that only the specified fields should be included.

Child elements can be customized by using a query string arg of either excludeElements or includeElements. This single parameter should be a comma-separated list of element names. For example, a request with excludeElements=Media is asking for the Media elements to be omitted while the includeElements parameter indicated that only the specified elements should be included.

In addition to the above are the parameters includeOptionalFields and includeOptionalElements. These indicate that the fields/elements which are not normally included should be included in this request. One example is includeOptionalElements=musicAnalysis on metadata will include the musicAnalysis parameter which can be large and typically not needed by a client.

Trimming the response to only include what a client will actually use can result in much better performance, especially in large collections. Increasingly these are being used to select which data is fetched from the database. So if a client knows it will only ever use a few parameters from a request, it should specify those with includeFields.

Note that these inclusions/exclusions are treated as requests, not guarantees. Some endpoints will disregard them completely, and others may ignore them for specific items and insist on returning data that the client didn't necessarily ask for.

Media Providers

Media providers are general purpose entities which supply media to Plex clients. Their API describes the Plex Media Server API, via a set of features on the "root" endpoint of the provider. Media provider can be hosted by a media server or in the cloud, linked to a specific Plex account. This section explains media providers generally, and then provides the specific server-hosted APIs around media providers.

Client Guide to Media Providers

The philosophy behind media providers in general is to allow a common API between cloud servers and PMS, since the APIs are nearly identical to a normal PMS. The general guidelines are:

• Consume /media/providers instead of /library/sections

  The new providers endpoint give you a list of all providers exported by a server and their features. Remember that the library itself is considered a (very rich) provider! This change will also require changing the client to not hardwire paths on the server, but rather read them from the feature keys directly (e.g. scrobble and rating endpoints).

• Gate management functionality on the manage feature

  Server libraries allow management (e.g. media deletion). The correct way to gate this functionality is via the manage feature.

• Make sure key construction is correct for things like genre lists

  For example, /library/sections/x/genre returns a relative key for each genre, but there's nothing which says that the key can't be an absolute URL. This is why servers pass back fastKey separately so as to not break clients which don't do key construction correctly. Media providers do not pass back fastKey, but assume clients will be doing correct key construction.

• Don't call /library/sections/X/filters|sorts

  You can get all that information (and more) in a single call by hitting /library/sections/X?includeDetails=1. Media providers include the extra information by default.

• Respect the Type keys in /library/sections/x

  The top-level type pivots have their own keys, which should be used over the old "just append /all to the path and add the type" approach. Not only is this more flexible, it also allows for "virtual" pivots, like music videos inside a music library.

• Look for the skipChildren/skipParent attributes for shows

  Because of things like Podcasts, single-season shows can now be made to skip seasons. This is indicated by a skipChildren attribute on the show, or a skipParent attribute on an episode. If this is set on a show, the client should use /grandchildren instead of /children in the show's key.

Features

The list of supported features, along with the API endpoints each feature represents is shown in the following list. Note that each feature can define a custom endpoint URL, so it doesn't have to match the server API exactly.

• search: This feature implies that it supports search via the provided key.

• metadata: This feature implies that it supports metadata endpoint. For example, if the key were /library/metadata then the endpoints /library/metadata/X, /library/metadata/X/children and /library/metadata/X/grandchildren would be supported. This endpoint family allows browsing a hierarchical tree of media (e.g. show to episodes, or artist to tracks).

• content: This feature implies that the provider exposes a content catalog, in the form of libraries to browse (grid of content), or discover (via hubs). Each entry in the content feature can contain:

  • hubKey: This implies it supports a discovery endpoint with hubs.
  • key: This implies it supports a content catalog.
  • icon: Optional, specifies the icon used for a content directory.

  Each content feature can contain one or both of these keys, depending on the structure. More details on the various combinations are provided below.

• match: The match feature is used to match a piece of media to the provider's content catalog via a set of hints. As a specific example, you might pass in a title hint of "Attack of the 50 Foot Woman" and a year hint of 1958 for the movie type. The provider would then use all the hints to attempt to match to entries in its catalog.

• manage: The manage feature implies a whole host of endpoints around changing data inside a library (e.g. editing fields, customizing artwork, etc.). This feature is generally only available on an actual server and generally only to the admin.

• timeline: The timeline feature implies that the provider wants to receive timeline (playback notifications) requests from a client at the endpoint defined by key. The feature may additionally specify the scrobbleKey and unscrobbleKey attributes, which represent the endpoints which allow marking a piece of media played or unplayed.

• rate: This feature implies the provider supports the endpoint which allows rating content.

• playqueue: This feature implies the provider supports the play queue family of endpoints. The flavor attribute further specifies the subset; the only supported flavor is currently full.

• playlist: This feature implies the provider supports the playlist family of endpoints. If readonly is set, that means that the provider only allows listing and playing playlists (via play queue API), not actually creating or editing them.

• subscribe: This provider allows media subscriptions to be created. If the flavor is record then media can be recorded from this library (such as DVR). If the flavor is download then the user is allowed to download from this library.

• promoted: This feature allows the provider to supply an endpoint that will return a collection of "promoted" hubs that many clients show on a user's home screen.

• continuewatching: This feature allows the provider to supply an endpoint that will return a hub for merging into a global Continue Watching hub.

• collection: This feature implies the provider supports the collection family of endpoints.

• actions

  • removeFromContinueWatching - Action to remove an item from continue watching

• imagetranscoder - This feature implies the provider supports the image transcoder endpoints used to scale images for clients where memory and processor is at a premium

• queryParser - This feature implies the provider supports the media queries language below

• grid - This feature implies the provider supports displaying metadata in a grid over time (such as live TV)

Home discovery and browsable libraries

Shown in the example in /media/providers, in this media provider the first content directory is an item with only hubKey, meaning it only providers discovery hubs. This is the set of hubs covering the whole library which contains continue watching, recently added, recommendations, etc. It's essentially "landing page" for the provider.

The subsequent directories also have a browse key, which means they provide a list view of the content with options for filtering and sorting. EPG providers may have only the key and no hubKey.

Minimal provider

There's no requirement to provide the content feature, given that there are two other ways to access content within a provider: search and match. The former can contribute to global search, whereas the latter is used for things like the DVR engine; once media subscriptions are set up, they look for matching content using the match feature, and examined using the metadata feature.

Deeper Hierarchies

If you examine an app like Spotify, you'll see many of the concepts here apply to their content hierarchy. Their content screens are either grids or hubs. But one notable difference is that the content hierarchy runs a bit deeper than the examples we've examined thus far. For example, one of the top-level selections is "Genres & Moods". Diving into one of the genres leads to a discovery area with different hubs for popular playlists, artists, and albums from the genre. Selecting a mood leads to a grid with popular playlists for the mood. In order to support this sort of hierarchy, we need an extension to the regular library, which is a content directory. This allows us to nest content, without losing any of the power and features—for example, the grid with popular playlists could list filters and sorts specific for that grid. This is power you simply don't have with the old channel architecture.

Extensions to regular libraries

This section examines extensions to plain libraries which content providers can use, and which clients need to be aware of.

• Nested content directories: In regular libraries, there are fixed types of directories (e.g. shows, or music albums). In content providers, we want to have the ability to display other types of things (e.g. stations, or moods, or genres) as first-class things in a grid or discovery layout. Here's an example of what a nested content directory looks like. Given the type of content, the client knows that this directory should be treated like a content directory feature entry.

  {
    "Directory":[
      {
        "key":"foo",
        "hubKey":"foo2",
        "type":"content",
        "aspectRatio":"1:1",
        "title":"Genres and Moods"
      }
    ]
  }
  

• Aspect ratio hint: Because the entities listed in content directories can be arbitrary, it's important to tell the client some information about how they should be displayed. The thumb attribute contains no information about aspect ratio, so clients make assumptions based upon known types (e.g. movies are 2:3, episode thumbs are 16:9, etc.). This attributes allows the provider to specify exactly the aspect ratio of the thing being displayed.

Metadata Providers

This section describes the specific Media Providers which supply the metadata feature. These providers can be created and used in Plex Media Server to supply metadata to items inside Movie and TV Show libraries (music libraries are currently not supported).

Common Request Headers

There are a few headers which are common to both the Metadata and Match features. These can be passed as either headers or query parameters.

Response Paging

Certain responses may contain a large number of objects. The consumer may want to limit the size of the MediaContainer by paging through them using the X-Plex-Container-Size and X-Plex-Container-Start headers/params. Responses should them limit the object count inside the MediaContainer to X-Plex-Container-Size and start at the index provided by X-Plex-Container-Start.

See the Pagination section for more details on how paging works.

The only two endpoints that require mandatory paging are the Metadata /children and /grandchildren endpoints as these will potentially contain many items. Passing no paging headers here should only return the first 20 Metadata objects.

Common return codes

It is important to return the correct HTTP return codes.

Response Customization (Optional)

There may be cases where a reduced response is wanted, i.e. we only want to return specific attributes or exclude specific attributes. These are handled with includeFields, excludeFields, includeElements and excludeElements.

Information on its use can be found in the Response Customization.

You may wish to add support for this to keep response sizes down, however it is not required and you can safely ignore when these parameters are passed.

Metadata Feature

This is a path to retrieve metadata for a specific piece of content by its id.

It is called by making a GET request to the path defined by the Metadata feature inside the root of your provider with the ratingKey of the metadata item.

For example, the request may be something like GET http://localhost/library/metadata/tmdb-movie-123 which should return a Metadata Object for the item with the ratingKey of "tmdb-movie-123".

See some Example Responses

Supported Query Parameters

There are some query parameters available to media provider to augment the responses. Not all of these are required to be supported by all providers, support requirement is detailed in the below table.

Image endpoint (Recommended)

The Metadata feature should also provide a /images path for calls to specific items, e.g. /library/metadata/tmdb-movie-123/images. This endpoint should return a MediaContainer object containing and Image Array of all the available image assets for that item.

Example:

{
  "MediaContainer": {
    "offset": 0,
    "totalSize": 3,
    "identifier": "tv.plex.provider.metadata",
    "size": 3,
    "Image": [
      {
        "type": "coverPoster",
        "url": "https://image.tmdb.org/t/p/original/qk3eQ8jW4opJ48gFWYUXWaMT4l.jpg",
      },
      {
        "type": "background",
        "url": "https://image.tmdb.org/t/p/original/3uE9SUywNbj1qSAuYCGgbTTYku5.jpg",
      },
      {
        "type": "clearLogo",
        "url": "https://image.tmdb.org/t/p/original/rIi0lY2UftYuKDJ4OlIefDdijve.png",
      }
    ]
  }
}

Children and Grandchildren Requests

For items which contain child items, like TV Shows and Seasons, these types should also respond to requests for /children and /grandchildren, e.g. /library/metadata/tmdb-show-123/children.

For TV Shows and Seasons this should return a MediaContainer object with an array of Metadata Objects for their Seasons and Episodes respectively.

It is required that these two endpoints support paged requests via the X-Plex-Container-Size and X-Plex-Container-Start headers/params.

Match Feature

This is a path to retrieve potential matches to metadata items based on contextual hints passed in your request body. This should return a MediaContainer Object possibly containing multiple Metadata objects (by default should only return the best result only).

It is called by making a POST request to the path defined by the Match feature inside the root of your provider.

This may be where it is useful supporting Response Customization as match responses don't always need to contain the full Metadata object responses.

A request body is required which can contain the attributes listed below.

Match Example

JSON Body

{
  "parentTitle": "Adventure Time",
  "type": 3,
  "index": 8,
  "filename": "TV Shows/Adventure Time/Adventure Time S08E01.mp4",
  "includeElements": "Metadata,Children",
  "includeFields": "guid,parentGuid,title,parentTitle,thumb,parentThumb,index,originallyAvailableAt,year,type",
  "includeChildren": 1
}

CURL Command

curl  -X POST \
  'http://localhost/library/metadata/matches?X-Plex-Country=US&X-Plex-Language=en-US' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "parentTitle": "Adventure Time",
  "type": 3,
  "index": 8,
  "filename": "TV Shows/Adventure Time/Adventure Time S08E01.mp4",
  "includeElements": "Metadata,Children",
  "includeFields": "guid,parentGuid,title,parentTitle,thumb,parentThumb,index,originallyAvailableAt,year,type",
  "includeChildren": 1
}'

Response

{
  "MediaContainer": {
    "offset": 0,
    "totalSize": 1,
    "identifier": "tv.plex.provider.metadata",
    "size": 1,
    "Metadata": [
      {
        "guid": "plex://season/5d9c0939e9d5a1001f4def89",
        "type": "season",
        "thumb": "https://image.tmdb.org/t/p/original/zIDoU6YZXE3oz9MNBjE2Ld94Xuu.jpg",
        "title": "Season 8",
        "parentTitle": "Adventure Time",
        "parentThumb": "https://image.tmdb.org/t/p/original/qk3eQ8jW4opJ48gFWYUXWaMT4l.jpg",
        "parentGuid": "plex://show/5d9c07f72df347001e3a70b4",
        "index": 8,
        "originallyAvailableAt": "2016-03-26",
        "year": 2016,
        "Children": {
          "size": 2,
          "Metadata": [
            {
              "guid": "plex://episode/5eeb4fc1d39938003f7753c0",
              "type": "episode",
              "thumb": "https://image.tmdb.org/t/p/original/3WXclCno2MYKhdnUidQVsPSpolk.jpg",
              "title": "Broke His Crown",
              "parentTitle": "Season 8",
              "parentThumb": "https://image.tmdb.org/t/p/original/zIDoU6YZXE3oz9MNBjE2Ld94Xuu.jpg",
              "parentGuid": "plex://season/5d9c0939e9d5a1001f4def89",
              "index": 1,
              "originallyAvailableAt": "2016-03-26",
              "year": 2016
            },
            {
              "guid": "plex://episode/5eeb4fc1d39938003f7753be",
              "type": "episode",
              "thumb": "https://image.tmdb.org/t/p/original/mhhq4BXNmnZZfzfqsBvZwMvcngt.jpg",
              "title": "Don't Look",
              "parentTitle": "Season 8",
              "parentThumb": "https://image.tmdb.org/t/p/original/zIDoU6YZXE3oz9MNBjE2Ld94Xuu.jpg",
              "parentGuid": "plex://season/5d9c0939e9d5a1001f4def89",
              "index": 2,
              "originallyAvailableAt": "2016-04-02",
              "year": 2016
            }
          ]
        }
      }
    ]
  }
}

MediaProvider Response

This document describes the JSON response schema for Plex-compatible metadata-specific Media Providers.

The root of the Media Provider must return some necessary attributes which define a metadata provider.

MediaProvider

Types Array (Required)

This defines what metadata types are supported by the provider.

Please note that is recommended to support one specific metadata parent type per provider as this will make it easier for consumers to combine this provider with others inside Plex Media Server. This is because in order to combine providers, each provider in a combine group must support the types the other supports as well. Limiting the scope of types will make it more widely compatible.

If you wish to support both movie and TV Shows, consider creating two separate providers. This isn't a hard requirement but is recommended.

When supporting TV Shows, it is necessary to add a type for TV Shows, Seasons and Episodes (i.e. types 2, 3 and 4).

…(truncated)