Manifest

The manifest sits at the root of the plugin folder and declares everything the plugin offers.

The manifest is a contract, not a description. Fluxta populates its UI from the manifest and ignores anything the code registers that the manifest did not declare — an Action, a Value Source, an Options Source, or an Event Source. If something registered never gets called, check this file first.

Example

{
  "name": "obs",
  "apiVersion": 1,
  "version": "1.2.0",
  "title": "OBS",
  "description": "Control OBS Studio from your deck.",
  "main": "index.mjs",
  "icon": "icon.svg",
  "editor": "editor/plugin.html",

  "author": "Jane Doe",
  "license": "MIT",
  "repository": "https://github.com/janedoe/fluxta-obs",
  "minAppVersion": "0.1.0",
  "maintainers": ["janedoe"],
  "platforms": ["windows", "macos", "linux"],
  "categories": ["streaming"],

  "actions": [
    {
      "name": "Switch Scene",
      "type": "switch-scene",
      "editor": "editor/index.html",
      "produces": [
        { "key": "previousScene", "name": "Previous scene", "type": "string" }
      ]
    }
  ],

  "sources": [
    {
      "key": "currentScene",
      "name": "Current scene",
      "type": "string",
      "operand": { "editor": "select", "options": "scenes" }
    }
  ],

  "events": [
    {
      "type": "scene-changed",
      "name": "Scene changed",
      "fields": [{ "key": "scene", "name": "Scene", "type": "string" }]
    }
  ]
}

Naming

Two shapes of identifier recur through the manifest, and each takes a fixed casing that fluxta validate/publish check:

• A kind — actions[].type, events[].type — is kebab-case (switch-scene, scene-changed). The host only ever compares it by string equality (against the class type passed to registerAction, or the string passed to emitEvent), so it's never read as a JS property.
• A key — sources[].key, produces[].key, params[].key, fields[].key, and a sources[].operand.options reference — is camelCase (currentScene, previousScene, appRunning). It's read as a literal JS object property everywhere the SDK touches it (ctx.settings.<key>, ctx.args.<key>, the object onTrigger returns, the emitEvent payload), so camelCase is what keeps dot-notation and object-literal shorthand valid.

Top-level fields

A missing required field is a load error: the plugin does not appear at all. The same is true of a duplicate name and of an apiVersion other than 1.

Paths in icon and editor are resolved against the plugin folder when the catalog is built. A path pointing at a file that does not exist is treated as if the field were absent, not as an error.

Package metadata

These extra top-level fields are ignored at runtime; most are required to publish. fluxta create seeds author, minAppVersion, categories, and platforms from your answers, writes license as MIT, and leaves repository, homepage, and maintainers empty. fluxta publish then fills in maintainers from the GitHub account you authenticate as, and repository from the package's origin git remote when neither repository nor homepage is set.

MIT is the only licence the Marketplace accepts; no other value is allowed.

List in platforms only the systems you have run the plugin on. A plugin written in plain JavaScript usually runs everywhere; one that loads a native module or calls an API only one system has does not. The Marketplace checks platforms, not Fluxta itself: a plugin installed by hand still starts on any system.

categories takes one to three of these:

See Publishing for how these fields are checked.

actions[]

produces[]

A value returned from onTrigger is stored only if its key is declared here and its runtime type matches type. Undeclared keys, non-scalar values, and type mismatches are dropped with a warning, as is everything returned by an Action that declares no produces[] at all. See Run Variables.

sources[]

A Value Source is a fact an If/Else step can branch on.

The two resolve flavours are covered in Value Sources.

params[]

Parameters narrow a source — "is this scene active", "is the timer named this running". The user fills them in when building the condition, and the whole set arrives as args in resolve.

Parameter values are always strings.

operand

By default the user types the value a condition compares against. Give the source an operand and they pick it from a live list instead:

"operand": { "editor": "select", "options": "scenes" }

Both keys are required, and editor must be exactly "select"; anything else falls back to a plain input. options names the Options Source the plugin registers with registerOptions — camelCase, like every other key, since it has to match that Options Source's own key exactly. See Operand options.

events[]

An Event Source is something the plugin announces with emitEvent, which a user can build an automation on.

fields[]

Fields are what a user filters an Event on, and they are readable as Run Variables inside that Event's Action list. See Events.

Where Fluxta looks for plugins

Installed plugins live in the plugins/ folder of the application's data directory, one subfolder each. Every subfolder is scanned for a manifest.json, and a folder without one is skipped silently.

During development, a development link overlays any installed plugin with the same name.