The integration catalog is live

Swirls workflows and agents call third-party APIs through typed, reviewable blocks in your .swirls files. Today we are shipping the integration catalog: more than 120 curated actions across Slack, GitHub, Linear, and Microsoft Graph, each one installable with a single command.

swirls add slack
swirls add linear create_issue
swirls add microsoft send_mail list_calendar_events

Every action lands in your project as a .swirls block you can read, diff, and review.

#Three blocks

An integration in Swirls is three declarations, and all three live in your files.

An action says what a call is: the transport, the schemas, and the OAuth scopes it needs.

action slack_post_message {
  provider: slack
  method: POST
  path: "/chat.postMessage"
  encoding: form
  scopes: ["chat:write"]
  input: @json { { "type": "object", "required": ["channel", "text"], "properties": { "channel": { "type": "string" }, "text": { "type": "string" } } } }
  output: @json { { "type": "object", "required": ["ok"], "properties": { "ok": { "type": "boolean" } } } }
}

A connection says who is calling. It is a named, project-scoped slot: the file holds the name, the Portal holds the grant. A human authorizes it once, and Swirls issues a short-lived token for each call at run time.

connection team_slack {
  label: "Team Slack"
  provider: slack
}

An integration node puts the call in a workflow. The transport and schemas come from the action, so your params are checked at deploy time and the node output is typed downstream.

node post_slack {
  type: integration
  connection: team_slack
  action: slack_post_message
  params: @ts {
    return {
      channel: context.nodes.root.output.channel,
      text: context.nodes.root.output.text,
    }
  }
}

#Why we built it

Swirls is agentic systems as code. The agents, the workflows, the triggers, and the access rules all live in .swirls files. Integrations were the last piece that lived outside the file, and in most stacks they still do: the call hides in glue code, the key sits in an environment variable, and the scopes sit in a provider dashboard nobody opens during review.

The catalog moves all three into the file. An action declares scopes: ["chat:write"] in the diff, so the reviewer sees what the workflow can do before it merges. A connection is a name in the file and a grant in the Portal, so credentials stay out of your repo and out of your vault.

Agents gain the most. An agent can author the connection, install the actions, and wire the nodes end to end, because every step is a file edit or a CLI command. Granting access stays a human step by design: the OAuth consent screen lives in the Portal. You review the diff, you click authorize, and the system runs.

#What ships today

Provider	Actions	Coverage
Slack	1	Post messages to channels, DMs, and conversations.
GitHub	8	Repos, issues, and pull requests.
Linear	7	Issues, comments, teams, and viewer.
Microsoft Graph	106	Mail, calendar, contacts, OneDrive, OneNote, Teams, and SharePoint.

Microsoft Graph is the deep end: 106 hand-curated actions covering the surfaces operations teams automate most, from sending mail and booking calendar events to uploading files into SharePoint document libraries. Swirls-brokered OAuth also backs Discord and LinkedIn today for agent channels.

#Any provider, on request

Slack, GitHub, Linear, and Microsoft Graph are the providers we have curated so far. The OAuth brokering underneath is provider-agnostic, and there are three ways past the list today.

Generate actions from any spec. Point swirls add at an OpenAPI or GraphQL URL and it produces the same typed action blocks the catalog ships:

swirls add https://api.linear.app/graphql --only viewer
swirls add https://petstore.example.com/openapi.json

Bring your own credentials. Self-managed connections declare a base_url and an auth profile. Any API you hold credentials for works today, through the same typed nodes.

Request the next provider. Declare the connection for the provider you want, deploy, and click Request support on your project's Connections page. Tell us the scopes you need and we prioritize enabling it. Adding a provider is curation work on our side, and your requests decide the order.

#Get started

Browse the catalog, run swirls add, and deploy with git push or swirls deploy. Your project's Connections page lists every declared slot; authorize each one once and the system is live. The full reference for actions, connections, and integration nodes is at swirls.ai/docs/connections/actions.