> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://mediakind.ferndocs.com/platform/how-to/live/core-concepts/templates/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://mediakind.ferndocs.com/_mcp/server. # Templates The live resource spec controls what to do: which inputs to accept, where to send output, when to run. What it does not control is how to encode. Codec settings, bitrate, output resolution, frame rate are complex, reusable settings that would be cumbersome to repeat in every resource you create. Templates solve this. You upload your encoding settings once to the **Templates API**, give the template a name, and reference it from as many live resources as you need. This means you can share the same encoding configuration across many resources and update it in one place when settings change. ## Reference a template Templates are managed through the Templates API and are completely separate from the Live API. Each time you upload a new version, the platform tracks it. The most recently uploaded version is automatically tagged `latest`. Reference a template in a live resource spec like this: ```json "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" } } ``` The `configRef.name` value must identify a customer config, not a MediaKind preset. Create the config from a preset first, then retrieve the config and read `status.inputPins` and `status.outputPins`. These pin names provide the `transformInput` and `transformOutput` values for the resource. The `latest` tag is mutable. Pin `configRef.version` to a version hash for production workflows that must remain reproducible. ## Customize a resource configuration There are two ways to adjust a template’s behavior for a single resource, without changing the shared template itself. ### Use declared parameters The first, and the one to prefer, is `configValues`. A template can optionally declare a set of named parameters, each one pointing at a specific location (or several) inside the template’s content. If a template declares a parameter, you can set it by name in `configValues` on the resource that references that template: ```json "encodingLive": { "configRef": { "name": "my-encoding-template", "version": "latest" }, "configValues": { "": "" } } ``` Add `configValues` only for parameters listed in the created config’s `spec.parameters`. Replace the placeholders with a declared name and its required leaf JSON value. You cannot invent a parameter name on the resource side. See Manage templates for how a template declares them. ### Apply direct overrides The second way is `configOverrides`, which applies JSON Patch operations directly against the template’s content, at any path, whether or not the template author intended it to be changed. It’s more powerful, since it isn’t limited to declared parameters, but it requires knowing the template’s internal structure in detail. If both `configValues` and `configOverrides` touch the same field, `configValues` is applied first and `configOverrides` applied second, so `configOverrides` wins. Alongside `configRef`, `configOverrides`, and `configValues`, the same object accepts an `advancedSettingsName` field. This points at an advanced-settings configuration block that MediaKind manages on your behalf. You will not normally set this yourself. Leave it out unless MediaKind support has specifically asked you to reference one. ## Template types The template types used by the four documented Live API resource types are: | Config type | Required by | Purpose | | -------------------- | ------------------------------------------------------- | ------------------------------------------------------------------ | | `encodingLive` | All four resource types | Live encoding parameters | | `multiviewComposing` | StaticMultiviewChannel, StaticMultiviewEvent (optional) | Composition layout for multiview, defined separately from encoding | | `streamConditioning` | Optional on any | Stream conditioning parameters | ## What comes next Build with the Templates API: every endpoint, presets, and the full config type reference. * Resource states: `spec.state` vs. `status.state`.