The workflow schema door publishes a bare document
A workflow's declared input and output ports, read by an editor before it can draw the workflow. It is not wrapped in the standard envelope, and its snake_case is as much a contract as the playground's camelCase.
The rule
Normative: this is the rule
- A successful read of a workflow's schema answers exactly
{schema_version, parameter_schema, output_schema}in that order, snake_case, with nosuccesskey and nodatawrapper. parameter_schemaandoutput_schemaare the stored snapshot verbatim, and where a workflow declares no ports they are JSONnull(not an empty object, and not omitted), so a consumer can distinguish "no ports" from "key missing".
What it means
This door answers with no envelope at all: no success, no data, just the
three keys themselves. And where a workflow declares no ports, the missing
schema is null, not an empty object and not a key left out — the three
shapes ("no ports", "an empty object", "key missing") would otherwise all
look the same to a consumer that has to guess which one it is looking at.
Example
A workflow with both a declared input and a declared output:
GET /api/flowdrop/workflows/{id}/schema
{"schema_version": "2.1.0", "parameter_schema": {"type": "object", "properties": {"name": {"type": "string"}}}, "output_schema": {"type": "object", "properties": {"result": {"type": "string"}}}}A workflow that declares no ports at all:
GET /api/flowdrop/workflows/{id}/schema
{"schema_version": "0.0.0", "parameter_schema": null, "output_schema": null}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-4 · changed in spec 1.0