--- name: pp-plexctl description: "Printing Press CLI for Plexctl. ## Content Types The API supports responses in both XML and JSON" author: "keithah" license: "Apache-2.0" argument-hint: " [args] | install cli|mcp" allowed-tools: "Read Bash" metadata: openclaw: requires: bins: - plexctl-pp-cli install: - kind: go bins: [plexctl-pp-cli] module: github.com/mvanhorn/printing-press-library/library/media-and-entertainment/plexctl/cmd/plexctl-pp-cli --- # 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: ```bash 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: ```bash 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: | Header | Description | Sample | | --- | --- | --- | | X-Plex-Client-Identifier | An opaque identifier unique to the client | abc123 | | X-Plex-Token | An authentication token, obtained from plex.tv | XXXXXXXXXXXX | | X-Plex-Product | The name of the client product | Plex for Roku | | X-Plex-Version | The version of the client application | 2.4.1 | | X-Plex-Platform | The platform of the client | Roku | | X-Plex-Platform-Version | The version of the platform | 4.3 build 1057 | | X-Plex-Device | A relatively friendly name for the client device | Roku 3 | | X-Plex-Model | A potentially less friendly identifier for the device model | 4200X | | X-Plex-Device-Vendor | The device vendor | Roku | | X-Plex-Device-Name | A friendly name for the client | Living Room TV | | X-Plex-Marketplace | The marketplace on which the client application is distributed | googlePlay | `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 `key`s, 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 | Type Name | Type Number | | -- | -- | | `movie` | 1 | | `show` | 2 | | `season` | 3 | | `episode` | 4 | | `trailer` | 5 | | `person` | 7 | | `artist` | 8 | | `album` | 9 | | `track` | 10 | | `clip` | 12 | | `photo` | 13 | | `photoalbum` | 14 | | `playlist` | 15 | | `playlistfolder` | 16 | | `collection` | 18 | 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: ```json [ { "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 `/chil