An action is what a step does. HTTP-backed actions register an endpoint — a URL that Mobius POSTs to when the step runs — along with JSON schemas that make the contract between step and implementation explicit. Platform-provided integration actions (such as Slack or GitHub) appear in the same catalog alongside actions you register yourself.

The model

Each registered action has:

• A name — the stable, project-scoped identifier referenced in workflow step definitions. Lowercase alphanumeric and hyphens; names starting with mobius. are reserved for platform integrations.
• An endpoint URL — the HTTP or HTTPS URL Mobius POSTs to when invoking the action.
• Input and output schemas — JSON Schema objects describing the expected parameter shape and return value.
• Annotations — safe-use hints: idempotent (safe to retry automatically), destructive (irreversible side effects), or read_only (no side effects; eligible for dry runs).
• A signing secret — Mobius computes HMAC-SHA256 over the request body and attaches it as X-Mobius-Signature. The raw secret is returned once, on creation or rotation only.

Actions fall into three kinds depending on where they execute:

A plain action field in a workflow step targets a worker-kind action and creates a job. Set action_kind: "server" to invoke a server-side action — including platform integrations — without dispatching a job.

A document-processing workflow

steps:
  - name: summarize
    action: summarize-document
    parameters:
      doc_id: "${inputs.doc_id}"
 
  - name: notify
    action: slack.post-message
    action_kind: server
    parameters:
      channel: "#ops"
      text: "Summary complete for ${inputs.doc_id}"

When this workflow runs, Mobius dispatches a job for the summarize step, which an external worker claims and executes against the registered summarize-document endpoint. The notify step calls the platform-provided slack.post-message action inside Mobius without creating a job.

Where you see it

• Dashboard — Projects → <project> → Actions lists all project actions with their endpoint URLs and annotation badges. The Recent invocations table below shows the action log for the project.
• API — the Actions tag covers creating, updating, deleting, and rotating signing secrets for project actions, plus catalog browsing and the action audit log. Filter the audit log by run_id to inspect every action call within a single workflow run, or by action_name for cross-run analysis.

See also

• Workflows — how steps and actions are assembled into a graph.
• Steps — each step references exactly one action.
• Jobs — what a worker-kind action creates for an external worker to claim.