FlowDrop Workflow Specification 1.0-draft

The category list is the standard envelope, and its name is a machine name

This is the list that fills an editor's node sidebar. A consumer that treats name as human-readable renders a machine name to an author.

The rule

Normative: this is the rule
  1. The category list answers the standard {success, data} envelope; a cacheable response carries byte-identical envelope keys to a non-cacheable one, and a door must not hand-build a body to avoid it.
  2. data is a list of rows whose keys are name, label, icon, color, description, in that order, every value a string.
  3. name is the category's identifier, not a display name, and there is no separate id key.
  4. Only enabled categories are published: a disabled one is absent rather than flagged, so a consumer cannot distinguish it from a deleted one.

What it means

name is the category's identifier, not a label a consumer may render as one — there is no separate id key to reach for instead, so a consumer that shows name to an author is showing a machine name. And the list is a filtered view, not a flagged one: a disabled category is left out entirely, which means a consumer cannot tell "disabled" apart from "never existed" — both look like the category is simply absent.

Example

One enabled category, alongside a disabled one that never appears at all.

Two stored categories, one disabled200 — served
GET /api/flowdrop/categories

{"success": true, "data": [{"name": "automation", "label": "Automation", "icon": "mdi:robot", "color": "#ABCDEF", "description": "Nodes that automate things."}]}

The disabled category contributes nothing to data — not a row with a flag, not a shorter row, no trace at all.

Rule identifiers are permanent and are never renumbered. Each implementation publishes its own standing against these rules; this specification does not.spec 1.0-draft · META-1 · changed in spec 1.0