Workflow Delivery steps
A Workflow delivery step requires id, type: delivery, endpointId, and nonempty templated content; event and next are optional. Event names are 1–100 allowed ASCII characters and default to workflow.step. At execution the outbound JSON envelope is exactly {workflowId, runId, stepName, content}. The step completes when enqueue returns queued, not when a Push receiver accepts it or a Pull consumer acknowledges it.
When an Agent creates or updates a graph containing this step, graph validation requires that same Agent’s endpoint write grant. A read grant is insufficient, while owner-authored graph writes do not require an Agent grant. Activation does not retroactively recheck a saved graph after a grant changes. Runtime dispatch remains owner-scoped, charges the owner’s credit, and shares the endpoint 60/minute plus owner 1,000/UTC-day Delivery quotas.
Delivery failure fails the Workflow run. In a loop, each visit sends and charges independently. A crash after enqueue commits but before the step completion record can leave one charged delivery with a failed run; inspect Delivery history before retrying. The durable step input stores only endpointId, event, and rendered contentBytes, while Delivery history also omits payload. Sent content therefore cannot be recovered from either UI. Use a notify step instead only for an internal owner Notification Center message; it never sends to an external endpoint and never fails the run when persistence or push fails.
Related actions
Section titled “Related actions”arinova.workflow.create_workflow, arinova.workflow.update_workflow, arinova.workflow.run_workflow, arinova.workflow.get_run, arinova.delivery.list_endpoints, arinova.delivery.send
Also known as
workflow delivery step, send workflow output outside, workflow.step, delivery contentBytes, workflow endpoint grant, 工作流程對外傳送
Build a7f47a5ca54ddcf7806cd48b81ce1b9827042766