---
{
  "id": "platform.delivery.workflow-delivery-steps",
  "topic": "delivery",
  "title": "Workflow Delivery steps",
  "locale": "en",
  "version": "2026-08-09",
  "summary": "A Workflow Delivery step queues a billed owner-scoped envelope, requires the authoring Agent's endpoint write grant, and deliberately retains no rendered content in run detail.",
  "content": "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.\n\nWhen 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.\n\nDelivery 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.\n",
  "aliases": [
    "workflow delivery step",
    "send workflow output outside",
    "workflow.step",
    "delivery contentBytes",
    "workflow endpoint grant",
    "工作流程對外傳送"
  ],
  "tags": [
    "delivery",
    "workflow",
    "billing",
    "permissions"
  ],
  "relatedActions": [
    "arinova.workflow.create_workflow",
    "arinova.workflow.update_workflow",
    "arinova.workflow.run_workflow",
    "arinova.workflow.get_run",
    "arinova.delivery.list_endpoints",
    "arinova.delivery.send"
  ],
  "relatedActionPrefixes": [],
  "url": "https://docs.arinova.ai/en/kb/delivery/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.