Callers can neither see nor supply a reserved input
A run that a caller starts has only the caller's rights, but the nodes after a trigger can still act on the site's behalf. Keeping reserved inputs out of reach means only a real firing, or a person testing one, can start that branch.
The rule
- A launch through the launch endpoint that supplies a key naming a reserved input (MAN-26) MUST be refused, on the same terms as MAN-13 refuses an undeclared key.
- A reserved input MUST NOT appear in the published contract.
- A reserved input MUST NOT appear in a model-facing tool schema built from the workflow.
- A reserved input MUST NOT appear among the input ports of a node that runs the workflow as a sub-workflow.
- An implementation MAY supply a reserved input when it starts a run because the trigger node fired, or when a person simulates a firing from an authoring surface.
What it means
Reserved inputs exist so that firings use the ordinary launch mapping, not so that callers can start a trigger's branch. A caller, an agent or a parent workflow sees only the declared inputs. A launch that names a reserved input anyway is refused like any other key the workflow does not accept.
A run started by a caller only ever has the caller's rights, but the nodes after a trigger can still use what the site has configured for them. Without this rule, anyone allowed to run the workflow could make up an event and set those nodes off.
What may supply a reserved input is left to the implementation: the trigger itself when it fires, and a person testing a trigger from the editor. Both are ways of starting a run that callers do not have.
Example
{ "inputs": { "event:on_update": { "ref": "node/42" } } }["article"]