Skip to content

Template format

A template repository is a Git repository containing JSON files at its root. Each template describes an integration’s required endpoints, grouped by upstream service type.

Save this as movie-reader.json:

{
"id": "movie-reader",
"name": "Movie reader",
"url": "https://example.com/movie-reader",
"endpoints": {
"radarr": {
"/api/v3/movie": ["get"],
"/api/v3/movie/{id}": ["get"]
}
}
}

This illustrative template grants read access to Radarr’s movie list and individual movie records. Replace the example URL with the integration’s actual project URL when publishing your own template.

Field Meaning
id Must match the filename without .json. Use a stable identifier, with no directory path.
name Required display name of the integration.
url The integration’s own homepage or repository, rather than the template repository.
endpoints Required map of service types to API paths and method lists.

Supported service-type keys are radarr, sonarr, lidarr, and prowlarr. Include only the services this integration uses.

Paths use the upstream API path, including the API version, such as /api/v3/movie. Do not include Middlewarr’s /proxy/{appSlug} prefix or your service’s deployment-specific URL base.

Use the parameter notation from the upstream OpenAPI specification, such as {id}, and lowercase method names such as get, post, put, patch, and delete.

Add repository.json at the root to describe the source:

{
"name": "My integration templates",
"description": "Templates for integrations used on my server."
}

This file provides display metadata. It does not change the repository’s identity or grant permissions.

Middlewarr derives a repository ID from the URL’s owner and repository segments. It qualifies template IDs with that source:

middlewarr/templates:homepage
my-account/my-templates:movie-reader

Inside movie-reader.json, the id remains movie-reader. Do not put the qualified ID in the file. Because the repository ID is derived from owner/name, repositories on different hosts with the same owner/name are not distinct namespaces.

Before submitting a template:

  1. Check that the file is valid JSON and its id matches its filename.
  2. Confirm every service type, path, and method against the upstream specification.
  3. Review write and delete access separately from read access.
  4. Load the source in a test installation, select the template on an app, and inspect the proxy’s effective endpoints.
  5. Exercise the integration’s connection test and the features the template is intended to support.
  6. Inspect access warnings for missing calls and verify unrelated operations remain blocked.

The template loader can log an unknown path or method as a warning rather than rejecting the whole file. Do not treat a successful sync as proof that all permissions are appropriate or that every route will work.

Open a pull request in the official template repository to contribute a new integration or correct an existing one. Describe the integration features and versions you tested, and explain why each added permission is needed.