manifest.json file. The manifest declares the plugin’s identity, the credentials it needs, and the functions it exposes. The build system reads the manifest to auto-generate the plugin registry, and the Portkey UI reads it to render configuration forms.
Complete example
The following is the manifest for the built-indefault plugin (plugins/default/manifest.json), trimmed to representative functions:
plugins/default/manifest.json
Top-level fields
Unique identifier for the plugin. Must match the directory name under
plugins/ and contain only lowercase letters, digits, and hyphens. This ID is used as the key in the generated plugin registry and in conf.json.Human-readable display name shown in the Portkey UI.
Short description of the plugin’s purpose. Displayed in the UI alongside the name.
Declares credentials the plugin requires (API keys, secrets, etc.). Set to an empty array Credential values are injected into
[] if the plugin needs no credentials.When credentials are required, define them as a JSON Schema object:parameters.credentials at runtime and are sourced from the credentials object in conf.json.Array of function definitions. Each entry declares one callable function exposed by this plugin. See Function fields below.
Function fields
Each object in thefunctions array must include the following fields:
Human-readable name for the function, shown in the UI.
Identifier for the function. Must match the TypeScript file name in the plugin directory (without the
.ts extension). Used as the key in the plugin registry.Function category. Accepted values:
| Value | Description |
|---|---|
guardrail | Evaluates content and returns a boolean verdict. |
transformer | Modifies the request or response payload. |
Array of hook names this function can run on. Accepted values:
"beforeRequestHook"— runs before the request is sent to the LLM."afterRequestHook"— runs after the LLM response is received.
Rich text description rendered in the UI. An array of content block objects. Each block has a Supported block types:
type and text:"subHeading", "text".JSON Schema object defining the parameters the function accepts. See Parameter schema below.
Parameter schema
Theparameters field uses a subset of JSON Schema to describe the inputs a function accepts. The UI uses this schema to auto-generate configuration forms.
Always
"object" for the top-level parameters definition.A map of parameter names to their schema definitions. Each parameter definition supports the following fields:
type
type
JSON Schema type of the parameter. Accepted values:
"string", "number", "boolean", "array", "object", "json".Use "json" for parameters that accept an arbitrary JSON object (e.g. a webhook headers map).label
label
Short label displayed next to the input field in the UI.
description
description
Rich text description array (same format as function-level
description). Rendered as hint text below the input.default
default
Default value applied when the parameter is not explicitly set. Type must match
type.enum
enum
Array of allowed string values. When present, the UI renders a dropdown selector instead of a free-text input.
items (for array type)
items (for array type)
Schema for individual array elements. Typically
{ "type": "string" } or a string schema with enum.encrypted (for credentials only)
encrypted (for credentials only)
Boolean. When
true on a credential field, the value is stored encrypted and never returned in plain text from the API.Array of parameter names that must be provided. The UI marks these fields as required.Set to
[] or omit the field if no parameters are required.Credential fields
When a plugin needs API keys or other secrets, define them in the top-levelcredentials schema:
conf.json and injected into the handler via parameters.credentials:
conf.json
Minimal manifest template
Use this as a starting point for a new plugin:manifest.json