Call outside systems without burying credentials in code.

Give your screens, steps, and assistants a named way to reach Slack, or anything else. Keep credential values outside the .swirls source and let Swirls supply them as the work runs.

Join private betaSee how it works

An external call should be explicit in the system.

Say which service, which action, what gets sent, and which login to use. Swirls hands the stored login to supported work as it runs and keeps the handoff in the history.

The file names everything you depend on.

One block describes the Slack call and what it accepts. Another names the account it goes through. The handoff has an obvious place in the file and in the record of the run.

Example: After an editor approves a draft, the publish process posts to Editorial Slack through a named account, with Swirls holding the login rather than the file.

Swirls owns the production work behind it.

Supplying supported credentials, running the work, and recording every handoff you described.

Name the action

Write down what gets sent and what comes back.

Keep the password out

Store the login with Swirls and supply it as the work runs.

Inspect the call

See the outside step in the same history as the rest of the work.

editorial/desk
editorial-desk.swirls
secret editorial_ops {
  label: "Editorial vendor keys"
  vars: [ OPENROUTER_API_KEY ]
}

connection editorial_slack {
  label: "Editorial Slack"
  provider: slack
}

node announce {
  type: integration
  label: "Announce in Slack"
  connection: editorial_slack
  action: slack_post_message
  params: @ts {
    return {
      channel: "#editorial",
      text: "Published: " + context.nodes.publish.output.title,
    }
  }
}
Credentials

  • Editorial Slack

    editorial_slack

    provider: slack · chat:write

    Sign-in held by Swirls

  • editorial_ops

    OPENROUTER_API_KEY

    Named here, never stored here

Covers

  1. Provider actions
  2. Stored logins
  3. What goes out and comes back
  4. Steps that call other tools
  5. Proof in the record
Read the technical docs

You own

Which systems to call, the fields and actions to use, the order of work, and every required approval.

Write the handoff down.

Name the service and the action, what crosses the line, which login to use, and what to do when it fails.

Join private betaSee how it works